templates / generics

[chriseth]

Solidity should support template types / generics for contracts, libraries, functions and structs.

The syntax should be as follows:

library listImpl[T] {
  struct List { T[] elements }
  function append(List storage self, T _e) {
    self.elements.push(_e);
  }
}

In general, at every point where a new library, contract, function or user-defined type is defined, you can suffix the name with [T1, T2, ...].

Inside the library, contract, function or user-defined type, the identifiers T1, T2, ... are bound to whatever they will be used with later. This means that type checking will not be done on those at the point where the template is defined.

At the point where a templated name is used, you have to prefix the name with [...], where inside the square brackets, an arbitrary expression is allowed. This will cause the template itself to be type-checked again, replacing the identifiers T1, T2, ... with the respective values.

On the implementation side, this means that the AST annotations now have to be context-sensitive. Every template variable will be assigned a compiler-global identifier. The annotation() function will receive an argument where these identifiers receive actual expressions. This argument will be transferred downwards in the AST during the second type checking phase.

[VoR0220]

any chance we can go full javascript on this and do this by using var as the generic type with a typeOf function to weed out unwanted types in the generics function?

[chriseth]

@VoR0220 I think what you are proposing is to basically do type checking at runtime, which is not a good idea in my opinion.

[VoR0220]

no it's more of a syntactic thing I think... could not [T] be substituted by var ?

[SCBuergel]

Any progress / timeline on this one? Seems to be a fantastic feature that is been around here for a while.

[axic]

A larger example from https://www.pivotaltracker.com/story/show/89907258:

Type-templated contracts, libraries, structs and functions, where type names are given after struct name in [] and concrete types in the same way at the point of instantiation.
Example:

struct Set[T] {
  uint m_lastIndex;
  mapping(T => uint) m_indices;
  mapping(uint => T) m_elements;
  uint constant notFound = 0;

  function insert(T _element) {
    if (find(_element) != notFound) return;
    uint index  = ++m_lastIndex;
    m_elements[index] = _element;
    m_indices[_element] = index;
  }
  function find(T _element) returns (uint index) {
    return m_indices[_element];
  }
  function remove(T _element) returns (bool removed) {
    uint index = m_indices[_element];
    if (index == notFound) return false;
    delete m_indices[_element];
    delete m_elements[index];
    return true;
  }
  function remove(uint _index) returns (bool removed) {
    if (_index == notFound) return false;
    delete m_indices[m_elements[_index]];
    delete m_elements[_index];
    return true;
  }
}

contract C {
  Set[address] m_owners;
}

Implementation details: Obviously, we cannot do type checking on the template struct, but only at the point of instantiation. This means that we need to create a kind of parellel AST node that contains the actual types. This might be the point where we separate the type checking from the AST and move it to its own visitor.

[chriseth]

@axic the implementation idea here was to use the annotation() function and provide as parameter to it the values for the template parameters. Whenever annotation(x) is not yet defined, run type checking over it again.

Having said that: I think the fastest way to achieve something like this outside the compiler is to use a simple preprocessor that only does string replacement, i.e. Set<address> -> Set_generic_address and then library Set<T> { ... } is copied to something library Set_generic_address { ... } where every T in {....} is replaced by address.

Perhaps that could be a feature request for truffle?

[nickbclifford]

Would this mean that things like uint[] would become Array<uint> and mapping (address => uint) would become Mapping<address, uint> or would generics be for user-defined types only?