On 8/20/13 3:38 AM, eles wrote:
> On Friday, 16 August 2013 at 21:07:52 UTC, Meta wrote:
>> A good, comprehensive design has the potential to make tuples easy to
>> use and understand, and hopefully clear up the unpleasant situation we
>> have currently. A summary of what has been discussed so far:
>>
>> - (a, b) is the prettiest syntax, and it also completely infeasible
>>
>> - {a, b} is not as pretty, but it's not that bad of an alternative
>> (though it may still have issues as well)
>>
>> - #(a, b) is unambiguous and would probably be the easiest option. I
>> don't think it looks too bad, but some people might find it ugly and
>> noisy
>
> What about:
>
> !!(a, b)
>
> ? Yes, is long, but is type-able quite fast.
>
> Alternative would be:
>
> ??(a, b)
>
> .

Somebody shoot me.

Andrei

On 08/20/2013 05:18 PM, bearophile wrote:
>>>>> s = "red blue"
>>>>> (a, b) = s.split()
>>>>> a
>> 'red'
>>>>> b
>> 'blue'
>
> It's supported in Haskell too:
>
> Prelude> let s = "red blue"
> Prelude> let [a, b] = words s
> Prelude> a
> "red"
> Prelude> b
> "blue"
>
> Bye,
> bearophile

Any language with algebraic data types supports this.

On 08/20/2013 09:57 PM, Timon Gehr wrote:
> On 08/20/2013 05:18 PM, bearophile wrote:
>>>>>> s = "red blue"
>>>>>> (a, b) = s.split()
>>>>>> a
>>> 'red'
>>>>>> b
>>> 'blue'
>>
>> It's supported in Haskell too:
>>
>> Prelude> let s = "red blue"
>> Prelude> let [a, b] = words s
>> Prelude> a
>> "red"
>> Prelude> b
>> "blue"
>>
>> Bye,
>> bearophile
>
> Any language with algebraic data types supports this.

(Some will only allow it if you can prove the match is total within them, of course.)

On 08/20/2013 08:51 PM, Andrei Alexandrescu wrote:
> On 8/19/13 11:39 PM, Timon Gehr wrote:
>> On 08/20/2013 02:18 AM, Andrei Alexandrescu wrote:
>>>
>>> Why would it be necessary to return an object of type TypeTuple (i.e.
>>> template tuple)?
>>
>>
>> - Elegance. Eg:
>>
>> auto seq(T...)(T arg){ return arg; }
>>
>> auto fold(alias a,S,R)(S start, R range){ ... }
>>
>>
>> seq(0,[1,2,3]).fold!((a,b)=>a+b);
>
> But this is again a value tuple not a template tuple, no?
>
> Andrei
>

In my understanding the former is a special case of the latter. Since you invented those terms, I might be mistaken. How do you distinguish between them?

On Tue, Aug 20, 2013 at 11:53:50AM -0700, Andrei Alexandrescu wrote:
> On 8/20/13 3:38 AM, eles wrote:
> >On Friday, 16 August 2013 at 21:07:52 UTC, Meta wrote:
> >>A good, comprehensive design has the potential to make tuples easy to use and understand, and hopefully clear up the unpleasant situation we have currently. A summary of what has been discussed so far:
> >>
> >>- (a, b) is the prettiest syntax, and it also completely infeasible
> >>
> >>- {a, b} is not as pretty, but it's not that bad of an alternative (though it may still have issues as well)
> >>
> >>- #(a, b) is unambiguous and would probably be the easiest option. I don't think it looks too bad, but some people might find it ugly and noisy
> >
> >What about:
> >
> >!!(a, b)
> >
> >? Yes, is long, but is type-able quite fast.
> >
> >Alternative would be:
> >
> >??(a, b)
> >
> >.
> 
> Somebody shoot me.
[...]

BANG!


T

-- 
They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill

On Tuesday, August 20, 2013 13:06:27 H. S. Teoh wrote:
> On Tue, Aug 20, 2013 at 11:53:50AM -0700, Andrei Alexandrescu wrote:
> > Somebody shoot me.
> 
> [...]
> 
> BANG!

Don't kill him. He hasn't finished the allocators yet! ;)

- Jonathan M Davis

On 8/20/13 6:57 AM, Dicebot wrote:
> I am proposing something more radical. Deprecate _both_ TypeTuple and
> Tuple. Clearly define the difference between built-in type tuple and
> expression tuple (latter being instance of former).

But that can't be the case.

> Preserve
> auto-expansion.

That would be problematic to say the least. (There have been a few discussions in this group; I've come to think auto expansion is fail.)

> Provide two different literals to remove ambiguity
> between referencing symbol as a value and referencing it as an alias.
> Make compiler auto-generate Tuple-like struct type for expression tuples
> that need to be returned from functions. Create some new type in
> std.typecons for those who don't want auto-expansion.
>
> It won't even break stuff.

That sounds good :o).


Andrei

On Tue, Aug 20, 2013 at 04:10:29PM -0400, Jonathan M Davis wrote:
> On Tuesday, August 20, 2013 13:06:27 H. S. Teoh wrote:
> > On Tue, Aug 20, 2013 at 11:53:50AM -0700, Andrei Alexandrescu wrote:
> > > Somebody shoot me.
> > 
> > [...]
> > 
> > BANG!
> 
> Don't kill him. He hasn't finished the allocators yet! ;)

Well, as my signature line said:

	They say that "guns don't kill people, people kill people." Well
	I think the gun helps. If you just stood there and yelled BANG,
	I don't think you'd kill too many people. -- Eddie Izzard,
	Dressed to Kill

;-)


T
-- 
Why can't you just be a nonconformist like everyone else? -- YHL

On 8/20/13 8:43 AM, Kenji Hara wrote:
> 2013/8/20 Dicebot <public@dicebot.lv <mailto:public@dicebot.lv>>
>
>     What we have here are two completely different _built-in_ tuple
>     types. "T" is pure template arguments list and is pretty much equal
>     TypeTuple!(int, int). But what is "args"? It uses the very same
>     built-in tuple syntax but it is much closer to std.typecons.Tuple in
>     its behavior (actually, latter is implemented in terms of it as I
>     was pointed out) - it is an entity that provides abstraction of top
>     of group of run-time values. It does not have any binary structure
>     on its own (built on top of existing values) but observable semantic
>     are very "run-time'ish".
>
>
> "args" is a built-in tuple of two function parameter variables. In
> binary level, args[0] and args[1] could be bounded to completely
> individual storage. (Even if args[1] is on stack, args[0] may be on
> register)
> On the other hand, std.typecons.Tuple is a struct. Its second field has
> the memory address which follows of the first field.

Ome question would be whether appropriate inlining could solve the performance disadvantage of Tuple.

Andrei

On Tuesday, 20 August 2013 at 20:16:54 UTC, Andrei Alexandrescu wrote:
> On 8/20/13 6:57 AM, Dicebot wrote:
>> I am proposing something more radical. Deprecate _both_ TypeTuple and
>> Tuple. Clearly define the difference between built-in type tuple and
>> expression tuple (latter being instance of former).
>
> But that can't be the case.

Can you elaborate on this? I can only judge by observable behavior which clearly says that typeof(TypeTuple!(2, 3)) is TypeTuple!(int, int). And when you use variadic template argument syntax in functions, you use "T..." (which is a built-in type tuple) to declare arguments (which is built-in expression tuple). There are probably some inconsistencies in implementation but this is the observable behavior that can be declared official.

>> Preserve
>> auto-expansion.
>
> That would be problematic to say the least. (There have been a few discussions in this group; I've come to think auto expansion is fail.)

:O it is awesome! Stuff like foo(myStructInstance.tupleof) is very powerful tool for generic interfaces. Do you remember any keywords to look for to find those discussions? Ones I remember were mostly about auto-expansion _not_ happening in some reasonable places.