On 25/03/2015 5:13 p.m., Andrei Alexandrescu wrote:
> On 3/24/15 8:00 PM, Rikki Cattermole wrote:
>> On 25/03/2015 7:11 a.m., Martin Nowak wrote:
>>> On 03/24/2015 03:11 PM, Vlad Levenfeld wrote:
>>>> Anything going on with this? Been looking forward to seeing it for
>>>> awhile.
>>>
>>> I think we should settle on a syntax and split DIP32 in a tuple part and
>>> a pattern matching part.
>>> The proposal wasn't yet formally accepted, partly because we wanted to
>>> wait, whether more needs come up. By now it's already 2 years old and it
>>> still looks complete IMO.
>>>
>>> http://wiki.dlang.org/DIP32
>>
>> 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

In that case, +1 on my vote for being complete.

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.

On Tuesday, 24 March 2015 at 23:07:29 UTC, Vlad Levenfeld wrote:
> You'd also have to rename opDollar to opHash or, maybe less confusingly, opPound.

opLength?

> Also, $ is already a common idiom (at least in Unix) for "the end". It would be better to just name

No, in Unix "$" is used in /bin/sh for the prompt and to denote a variable, but "$#" is used for the number of parameters and "${#variable}" is used for length. What you are thinking about is that "$" is used for pattern matching of the conceptual EOL-symbol (character) in regular expressions, but that's not length.
So in the Unix world "$" is either used for variables or pattern matching, and "#" is used for length.

In perl "$#" is used to denote last item in list? In Lua "#" is the length operator? Using "$" for length is just confusing if you know other languages.

Vlad Levenfeld:

> Anything going on with this? Been looking forward to seeing it for awhile.

It will happen.

Bye,
bearophile