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

Reply via email to