Add value type parameters RFC

[Zoxc]

Rendered view

[huonw]

Thanks for writing this up! This is definitely a desirable feature but should be able to be added after 1.0 in a backward compatible way.

Also it seems quite similar to #56, could read over that and highlight any differences? (If there aren't any meaningful ones, we can close this with the postponed label too.)

[emberian]

This RFC is incredibly light on details, and offers no concrete analysis on the impact to the type system or how this would be implemented, only presenting a "feel" for what this feature should look + act like. Specific feedback coming later, short on time atm.

[pczarn]

this still has to be const num: int

[lilyball]

Allowing uint is useful primarily for [T, ..n]. I can see why bool might be useful, although it's less obviously necessary than uint. I'm not at all convinced that any other type is worth supporting. Notably, I think arbitrary parameterized types might be better done via a different mechanism, that of associated values for traits (not associated types, but values).

I discussed this already with @Zoxc in IRC, but the short overview is as follows:

A trait can declare associated values via the static keyword. This might look like

pubtraitNumeric{staticMAX_VALUE:Self;staticMIN_VALUE:Self;
...
}

Similarly, impl blocks can then contain statics in addition to the existing fns. This would then look like

implNumericforuint{staticMAX_VALUE:uint = -1u;staticMIN_VALUE:uint = 0u;
...
}

With this ability, you can now provide the desired generic parameterized values by instead using a generic type that's bounded on a trait with the necessary values.

This approach should work for all generic value parameters. There's still a desire for uint parameters simply to avoid having to define a new type for every single possible numeric value that might want to be used. bool parameters could reasonably be represented using a trait Boolean and two phantom types (one for true, one for false), but that is a little cumbersome. Other value types I think have no compelling need to have special support when associated values should work just fine for them.

This would also generalize into an associated type scheme where trait and impl blocks can contain type definitions as well. Traits and impls would then effectively be mods, although I think it's reasonable to still prevent foreign fns and other mods from being defined inside them (but I could be convinced that perhaps it should be opened up to all items). This would work well for associated values because you could then use nested types as the phantom types you need.

Combined with field offsets (RFC PR #175), this would allow you to basically define a trait that requires implementors to provide certain fields. Clients of the trait can then access the fields via the associated values, and as long as the FieldOffset type properly inlines its accessors, this would theoretically let LLVM optimize the access down to the same code it would use for directly accessing the field of the instance type. The following is an example of doing this, where a single object provides information about multiple fields:

traitOffset<T,Ty>{staticOFFSET:FieldOffset<T,Ty>;}structObject{x:uint,y:uint}implObject{/// Phantom nested type that conforms to Offset for field `x`structFieldX;/// Phantom nested type that conforms to Offset for field `y`structFieldY;// this impl could alternatively go one level up and use `for Object::FieldX`// but I think it makes a bit more sense to be nested tooimplOffset<Object,uint>forFieldX{staticOFFSET:FieldOffset<Object,uint> = offsetof Object.x;}implOffset<Object,uint>forFieldY{staticOFFSET:FieldOffset<Object,uint> = offsetof Object.y;}}

With the above, you can now write code that looks like

fnfoo<T,Field:Offset<T,uint>>(x:&mutT){// double the given field*Field::OFFSET.get_mut(x) *= 2;
...}fnbar(x:&mutObject){foo::<Object,Object::FieldX>(x);}

The above is kind of trivial, but it actually represents something you can't do today, which is to provide mutable access to an object and to a field within the object simultaneously. Normally to provide field access you'd pass a &mut uint but that can't coexist with the &mut T. There are also more compelling examples with parameterizing types with Offset instead of functions (e.g. the internal-storage linked list that @Zoxc wants Field Offsets for).

A while back Servo wanted to be able to have traits define fields that implementors must provide. This was so the DOM implementation could directly access various common fields across DOM nodes without needing struct inheritance. Assuming it optimizes as well as I hope it will, I think associated values + field offsets would actually solve this need.

[Zoxc]

@kballard The entire point of this is to avoid having a type per value, although grouping often used multiple values together in a single type with associated items can be an alternative in certain cases. Furthermore your example doesn't use OFFSET in an static, just in a regular expressions, so it doesn't even need associated items.

There doesn't seem to be any significant differences with #56, so you can postpone this too.

[lilyball]

@Zoxc The use of OFFSET in a static is because it would then be usable in constexpr situations too, although I don't know how relevant that is at the moment.

[brson]

This feature comes up often. It's desirable, and it will probably happen, but not before 1.0. Let's postpone this and come back to it in the future.