uniform tuple syntax

[Vlad Levenfeld via Digitalmars-d]

On Wednesday, 25 March 2015 at 04:13:03 UTC, Andrei Alexandrescu 
wrote:
> On 3/24/15 8:00 PM, Rikki Cattermole wrote:
>> There is one thing blatantly missing atleast to me.
>> Unpacking into function arguments.
>>
>> void myfunc(int x, string y) {
>>     // ...
>> }
>>
>> myfunc({1, "hi!"}.unpack);
>
> myfunc(tuple(1, "hi!").expand);
>
> Andrei

Yeah, treating the builtin tuple the same way as, say, a 
TypeTuple, would be cool. For everything else, there's the 
library tuple. I've noticed that I can do

   TypeTuple!(arg1, arg2, arg3).func;

but this only works if the args are symbols (which can be 
aliased), but not for expressions. What I'd really like is to say

   {2 + 4, `he` ~ `llo`}.myfunc;

Without an explicit "tuple" or "expand". Also, putting something 
into a library tuple forces a copy, but I think it'd be nice if 
the symbols in builtin tuples could be ref. In other words, make 
{} mean roughly the same thing as TypeTuple (which have a 
misleading name as they can be used for everything, not just 
types, which is why I rename TypeTuple to Cons in my code).

On Tuesday, 24 March 2015 at 23:57:53 UTC, Adam D. Ruppe wrote:
> In this context, it would look like a delegate/function literal 
> or perhaps the start of a scope in other contexts.
>
> auto a = { arg1, arg2 }; // a is a function pointer, not a tuple
>  // ( that won't compile cuz of a missing semicolon inside but 
> still )
>
> { int }
>
> would look like a block scope. Again, it wouldn't compile 
> because the int is missing an identifier, but still, it would 
> pose a parsing problem.

So, the first case should be a tuple. As a function, {} means the 
same thing as (){}. I don't really like this, and never use this 
{} notation anyway, because my syntax highlighting chokes on it. 
In any case, requiring an argument list before a function 
definition would resolve the ambiguity.

In any case, the issue would come to light the moment "a" was 
actually used. "Tuples don't overload opCall" or something. Or it 
might get caught by some type-checking logic before that. Unless 
"a" were never used, in which case it doesn't really matter what 
it resolves to (unless it were being declared specifically to be 
stored or in TMP, in which case naming the explicit type is a 
better practice anyway).

As for the second, it should just be a TypeTuple, if anything. If 
that's not possible, then its an error. As for which error, I'd 
say its safe to assume its a scope and give the "no identifier" 
error.

On Tuesday, 24 March 2015 at 23:59:20 UTC, Brian Schott wrote:
> Before:
> auto x = {}; // struct or function?
>
> After:
> auto x = {}; // struct, function, or tuple??

For the before case, it's gotta be a function, because it doesn't 
make sense to use a brace-enclosed initializer without any type 
information.

The "after" case should be interpreted as a tuple, for reasons 
outlined above.