On Friday, 18 January 2019 at 10:23:11 UTC, Jacob Carlborg wrote:
On 2019-01-17 23:44, H. S. Teoh wrote:
YES! This is the way it should be. Type-tuples become first
class
citizens, and you can pass them around to functions and return
them from
functions
No no no, not only type-tuples, you want types to be first
class citizens. This makes it possible to store a type in a
variable, pass it to and return from functions. Instead of a
type-tuple, you want a regular array of types. Then it would be
possible to use the algorithms in std.algorithm to manipulate
the arrays. I really hate that today one needs to resort to
things like staticMap and staticIndexOf.
Of course, if we both get tuples and types as first class
citizens it would be possible to store types in these tuples as
well. But a tuple is usually immutable and I'm not sure if it
would be possible to use std.algorithm on that.
It would be awesome to be able to do things like this:
type foo = int;
type bar(type t)
{
return t;
}
auto u = [byte, short, int, long].map!(t => t.unsigned).array;
assert(u == [ubyte, ushort, uint, ulong];
Yes, you will be able to do exactly what you describe above.
type-tuples are strictly a superset of types; which also include
true compile-time constants. (e.g. things you can use to
instantiate a template with.)
Within type functions you are able to create `alias[]` which is
in some ways equivalent to type-tuple (and will be converted to
one upon being returned outside of compile-functions),which you
can append to if you own it and type functions can also take
other type-functions as parameters.
Therefore it's perfectly possible to implement staticMap in terms
of type functions.
I already did the semantic sanity checks, and it shows promise.
The only difference that type-functions have from what you
describe is that it does not need to occupy a keyword 'type'.
Cheers,
Stefan
