The Final(ize) Challenge

[Daniel Keep]

Andrei Alexandrescu wrote:
> Daniel Keep wrote:
>> ...
>>
>> It's hardly fair to issue a challenge which can only be completed [1]
>> with an unreleased compiler only you have seen.
> 
> I don't have 2.031 and I don't know whether it will fix the template
> constructor bug.

Dude, you got my hopes up with that.  :'(

>> Actually, that *still* isn't going to cut it: it won't handle ref or out
>> arguments correctly.  I'm not sure what it'd do with scope.
>>
>> We *really* need to come up with a sane solution to generalising on
>> storage class.  Every time I have to generate functions, they make my
>> life a complete pain in the arse.  The only solution I've found is this
>> hideous hack that parses ParameterTuple!(T).stringof and builds an array
>> of enums... yech.
> 
> It's much easier to parse ParameterTuple!(T)[n].stringof. If it starts
> with "ref "/"out " then it's a ref/out.

These magic tuples have a horrible habit of losing this invisible extra
information when you so much as think about them.  I didn't realise you
could safely index them.

What bothers me more is that as far as I can work out,
ParameterTuple!(T) shouldn't exist in D in its current form.  Its
elements aren't types since when you use .stringof on them, they know
their own storage class.  And I'm pretty sure you can't pass the tuple
around without it losing the storage classes (I gave up trying to figure
out exactly under which circumstances this happened and just passed the
function type's stringof around.)

Maybe the underlying is() expression could be changed to return
something like (StorageDefault, int, StorageRef, int, StorageOut, out)
instead (given that the Storage* types are defined in object.d as
typedefs of void or something.)  Or maybe have a new trait or is() form
that tells us the storage classes as with a tuple of strings.  Then we
wouldn't need to rely on a spec-defying feature.

  -- Daniel