September 24, 2012
On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
> On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer wrote:
>> Without any research or investigation, what about using a different
>> set of delimiters for tuples? Like {1,2,3}
>
> .... and exactly the syntax I was going to propose!

Assume you had this syntax working today. So instead of writing "tuple(a. b. c)" you write "{ a, b, c }". To what extent would your code be better? (Honest question. Don't forget that adding the => syntax for lambda /did/ make for better code.)


Andrei
September 24, 2012
On 9/24/12 11:29 AM, Andrei Alexandrescu wrote:
> On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
>> On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer wrote:
>>> Without any research or investigation, what about using a different
>>> set of delimiters for tuples? Like {1,2,3}
>>
>> .... and exactly the syntax I was going to propose!
>
> Assume you had this syntax working today. So instead of writing
> "tuple(a. b. c)" you write "{ a, b, c }". To what extent would your code
> be better? (Honest question. Don't forget that adding the => syntax for
> lambda /did/ make for better code.)
>
>
> Andrei

Hrm, I meant "tuple(a, b, c)".

Andrei
September 24, 2012
On Monday, September 24, 2012 16:00:06 David Piepgrass wrote:
> There is also no consideration in the DIP of what I consider one of D's most confusing "features": "pre-expanded tuples" or in other words, type tuples.

That's a completely separate issue. The DIP doesn't even introduce normal tuples into the language. It merely proposes that the comma operator be deprecated and uses the _possibility_ of introducing tuples into the language as an argument for that deprecation.

- Jonathan M Davis
September 24, 2012
On Mon, 24 Sep 2012 11:29:53 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
>> On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer wrote:
>>> Without any research or investigation, what about using a different
>>> set of delimiters for tuples? Like {1,2,3}
>>
>> .... and exactly the syntax I was going to propose!
>
> Assume you had this syntax working today. So instead of writing "tuple(a. b. c)" you write "{ a, b, c }". To what extent would your code be better? (Honest question. Don't forget that adding the => syntax for lambda /did/ make for better code.)

I can't honestly say I've used either tuple(a, b, c), or tuples in other languages very much.

I can say that I have *avoided* tuples as return values because I don't want to type Tuple!(x, y) as the return type.  But I haven't come across that need very much.  You can say "yeah, but what about auto?"  Cases I'm referring to were to make interface declarations -- can't use auto.

I can similarly say I have never had need to type x, b (i.e. use the current comma operator), except in for statements.

I'd be fine with getting rid of comma operator and not doing tuples in the language, but it certainly feels weird that we have a tuple type in the language, without any formal type unless you alias it (as std.tuple does).

It's almost like instead of saying:

int[] x;

you had to do:

typeof([1,2]) x;

Yeah, with alias, we could arrive at:

Array!int x;

But really, it seems odd that the language has a type for something that doesn't have a name/syntax.  Odd, but not unworkable.

I just wanted to point out that it seems the largest trouble, implementation-wise, for DIP19 is the choice of parentheses to denote a tuple.  If we do want to add built-in tuples, maybe we should be looking at a different delimiter.

-Steve
September 24, 2012
On Mon, 24 Sep 2012 11:47:09 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:


> I can say that I have *avoided* tuples as return values because I don't want to type Tuple!(x, y) as the return type.  But I haven't come across that need very much.  You can say "yeah, but what about auto?"  Cases I'm referring to were to make interface declarations -- can't use auto.

To further this, I would love to see something where "quick POD structs" can be constructed using some builtin syntax.

For example:

{valid:bool, value:int}

which would be equivalent to Tuple!(bool, "valid", int, "value")

I would *definitely* like to see that.  This might be on par with the => addition.

-Steve
September 24, 2012
On Mon, Sep 24, 2012 at 5:24 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
> I think my main problem with this is that I'm perfectly happy with the baseline, which has "tuple(" as the left delimiter and ")" as the right delimiter.

I found it a bit long compared to other languages in the beginning, but I've been using them heavily since you added them to Phobos and I'm now quite happy with them. I even like the .expand thingy.


(I have a few nitpicks, about std.typecons.tuple, but those would be
the subject of another thread)


> I'd be more excited to invent notation if there was overwhelming
> or at least considerable evidence that the notation considerably helps
> certain use cases, or is very frequent. As things are, I'd be quite "meh"
> about suddenly adding lenses.

OK.

One standard use for tuples is assignment:

a,b = someTuple;  // a and b already exist in this scope
auto (c,d) = someTuple; // creates c and d

and similar variations, which Phobos' tuples do not provide.
September 24, 2012
If tuples are ever introduced, I hope parentheses will not be used.

I would prefer something like this:

tuple<2,1,8>
September 24, 2012
Caligo:

> If tuples are ever introduced, I hope parentheses will not be used.
>
> I would prefer something like this:
>
> tuple<2,1,8>

That both breaks code, doesn't improve the syntax, but makes it worse.

Bye,
bearophile
September 24, 2012
On 9/24/12 11:47 AM, Steven Schveighoffer wrote:
> On Mon, 24 Sep 2012 11:29:53 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
>>> On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer
>>> wrote:
>>>> Without any research or investigation, what about using a different
>>>> set of delimiters for tuples? Like {1,2,3}
>>>
>>> .... and exactly the syntax I was going to propose!
>>
>> Assume you had this syntax working today. So instead of writing
>> "tuple(a. b. c)" you write "{ a, b, c }". To what extent would your
>> code be better? (Honest question. Don't forget that adding the =>
>> syntax for lambda /did/ make for better code.)
>
> I can't honestly say I've used either tuple(a, b, c), or tuples in other
> languages very much.
>
> I can say that I have *avoided* tuples as return values because I don't
> want to type Tuple!(x, y) as the return type. But I haven't come across
> that need very much. You can say "yeah, but what about auto?" Cases I'm
> referring to were to make interface declarations -- can't use auto.

Yah, after writing DIP19 I was like, "creating tuples is nice and easy, but expressing function returns is less so". Besides, the comma operator does not hurt the syntax for types all that much.

> I just wanted to point out that it seems the largest trouble,
> implementation-wise, for DIP19 is the choice of parentheses to denote a
> tuple. If we do want to add built-in tuples, maybe we should be looking
> at a different delimiter.

Indeed. The question is what mileage we get out of it.


Andrei


September 24, 2012
On Sunday, September 23, 2012 16:40:34 Andrei Alexandrescu wrote:
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19

My #1 concern here is that for loops do _not_ ever change how they function with regards to commas (which the DIP seems to do, but it also seems to imply that we might want to get rid of that later - which I do _not_ agree with). The comma operator is occasionally useful beyond for loops, but it's usually considered bad practice to do so, so if we want to get rid of it aside from for loops, then I have no problem with that. If anything, I'd argue that bringing tuples into the mix is muddying matters, since I think that there's a solid argument for deprecating the comma operator based solely on the problems that it causes even if we never add any other syntax which uses commas in a way that the comma operator prevents.

As to whether we add tuples or not, I don't know. Being able to do something like.

int i;
string s;

(i, s) = foo();

or

(auto i, string is) = foo();

would be useful, but I can live without it. std.typecons.tuple takes care of most of what you need from tuples IMHO. So, if we can find a way to cleanly add tuples to the language, I'm fine with that, but I'm also fine with leaving tuples as they are.

- Jonathan M Davis