B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

[H. S. Teoh]

On Fri, Jan 18, 2019 at 11:23:11AM +0100, Jacob Carlborg via Digitalmars-d-announce 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.

Yes, that would be the next level of symmetry. :-D  Types as first class
citizens would eliminate another level of distinctions that leads to the
necessity of staticMap, et al.  But it will also require changing the
language in a much more fundamental, invasive way.

So I'd say, let's take it one step at a time.  Start with first-class
type-tuples, then once that's ironed out and working well, take it to
the next level and have first-class types.  Trying to leap from here to
there in one shot is probably a little too ambitious, with too high a
chance of failure.


[...]
> 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 this would be awesome.  But in order to avoid unmanageable
complexity of implementation, all of this would have to be compile-time
only constructs.


T

-- 
Your inconsistency is the only consistent thing about you! -- KD