September 25, 2012
On 2012-09-25 00:28, bearophile wrote:

> (||)
> (|1|)
> (|1, 2|)
> (|1, 2, 3|)

What about:

||
|1|
|1, 2|


-- 
/Jacob Carlborg
September 25, 2012
On 24/09/12 17:19, Andrei Alexandrescu wrote:
> On 9/24/12 4:17 AM, Don Clugston wrote:
>> Regarding the comma operator: I'd love to deprecate it, but even if we
>> don't, could we at least ensure that this kind of rubbish doesn't
>> compile:
>>
>> void main()
>> {
>> int x;
>> x > 0, x += 5;
>> }
>>
>> At present, because comma expressions are expressions, not statements,
>> the "x > 0" doesn't generate a "statement has no effect" error, despite
>> the fact that it is meaningless and gets completely discarded.
>
> Interesting. The comma operator is probably the only one in which an
> expression is evaluated only for the sake of its side effects. So
> eliminating the comma operator would just get rid of that case by design.

Yes. Comma is a special case in a number of ways.

> Of course, there's always the option of adding more checks or rewriting
> the comma operator from "expr1, expr2, expr3" to "{ expr1; expr2; return
> expr3; }()".

We hit this one often in real-world code. On German keyboards , and ; are on the same key, so it's a fairly easy typo. I don't think it happens as often when using a US keyboard.

September 25, 2012
Le 25/09/2012 01:59, Andrej Mitrovic a écrit :
> On 9/25/12, Steven Schveighoffer<schveiguy@yahoo.com>  wrote:
>> However, this brings up another issue, what about porting C code?  All of
>> a sudden c style casts are no loner errors, but are type tuples!
>
> I think they're still errors:
>
> int x = (int)foo;
>
> Maybe the compiler could figure out if a cast was attempted rather
> than a tuple, and could print out the ol' "Can't use C shenanigans in
> D" error.

It will, because it is trying to parse an expression here, not a declaration.
September 25, 2012
Le 24/09/2012 17:29, Andrei Alexandrescu a écrit :
> 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

{} is often harder to disambiguate then () with current D syntax.
September 25, 2012
Le 24/09/2012 17:24, Andrei Alexandrescu a écrit :
> On 9/24/12 9:27 AM, Philippe Sigaud wrote:
>> On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
>> <SeeWebsiteToContactMe@semitwist.com> wrote:
>>
>>> That said, I'm not necessarily opposed to the strict separation if we
>>> had a good candidate for built-in tuple literal syntax. But *if* the
>>> best we have is parens (and maybe there *is* something better?) then
>>> maybe this would be an acceptable way to achieve it?
>>
>> If the problems in DIP 19 are deemed mostly syntactic (1- and 0-
>> element tuples), then maybe *for once* a simple syntax change could
>> solve them? I know syntax proposals are a dime a dozen in this
>> newsgroup, but why not here, to avoid the ((1)) problem?
>>
>> For example choosing { 1, 2} to represent a tuple? { } blocks in D
>> enclose semi-colon terminated declarations or expressions, but here
>> it's enclosing comma-separated expressions. And, since { } is probably
>> dangerous without a completly integrated type systems giving a type to
>> all expressions ( (){} anyone?) , why not use (| 1, 2 |), or whatever
>> syntax strikes our collective fancy? (I propose *not* to use< ,>)
>>
>> Then, the compiler has to change the way it prints its internal tuple,
>> to follow the new syntax.
>>
>>> Ie:
>>>
>>> // (3) is polysemous: Either int or (int)
>>> int a = (3); // Normal value
>>> (int) b = (3); // One-element tuple
>>> auto c = (3); // Default to normal "int"?
>>
>> For the third case, I'd say it defaults to a tuple. But then again,
>> using another syntax solves this problem.
>>
>> auto c = (| 3 |); // or c = { 3 };
>
> 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'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.
>
> Andrei

Clearly, crating a tuple that way isn't the issue. tuple() is ok.
September 25, 2012
Le 24/09/2012 17:55, Philippe Sigaud a écrit :
> 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.

And the auto flatten stuff is really weird, and sometime get into the way.
September 25, 2012
Le 25/09/2012 01:39, Andrei Alexandrescu a écrit :
> On 9/24/12 6:28 PM, bearophile wrote:
>> Timon Gehr:
>>
>>>> My bikeshed is colored one of these:
>>>>
>>>> (:1,2)
>>>> (|1,2)
>>>>
>>>
>>> At that point you might as well just use
>>>
>>> import std.typecons : q = tuple, Q = Tuple;
>>>
>>> Q!(int, int) foo(){
>>> return q(1, 2);
>>> }
>>>
>>> If built-in tuples are not going to look like
>>>
>>> (1, 2)
>>>
>>> then imho we might as well leave them out,
>>
>> But the banana syntax doesn't look bad:
>>
>> (||)
>> (|1|)
>> (|1, 2|)
>> (|1, 2, 3|)
>
> tuple()
> tuple(1)
> tuple(1, 2)
> tuple(1, 2, 3)
>
> also arguably enjoys the same advantages and in fact is much more
> intuitive. Like, totally intuitive. Like, it says "tuple" to create a
> tuple. And one advantage is, there's never ever going to be butt jokes
> about tuple() as there'd be with "(||)".
>

The problem with tuple() isn't its syntax, but what you can or can't do with the resulting tuple.
September 25, 2012
Le 25/09/2012 03:19, ixid a écrit :
> What would a special case where the first level of tuple (with higher
> levels being tuples in tuples) didn't require parens break? This would
> be a beautiful syntax:
>
> auto a = 1, 2; // A tuple of two ints
>
> int, string fun(double, double d) {
> return cast(int) (d[0] * d[1]), "hello";
> }
>
> auto a, b = 1, 2; // Two ints
> auto a = fun(1.0, 1.0); // Tuple of 1 and "hello".
> auto a, b = fun(1.0, 1.0); // An int and a string.
>

It can get pretty confusing with , separated declarations :

int a, b = 3;

or worse :

int a, int b = foo();
    -->
        (int a, int b) = foo();
      or
        int a, (int b = foo());

and it gets worse with int a, auto b = foo();

But I do agree that this is really nice in many places.
September 25, 2012
Le 25/09/2012 09:11, Jacob Carlborg a écrit :
> On 2012-09-25 00:28, bearophile wrote:
>
>> (||)
>> (|1|)
>> (|1, 2|)
>> (|1, 2, 3|)
>
> What about:
>
> ||
> |1|
> |1, 2|
>

Yeah and why not þ1, 2þ or ŀ1, 2ŀ ?

maybe ↓1, 2↓ is better ?

or « 1, 2 » (this one at least is readable).
September 25, 2012
Le 24/09/2012 16:59, foobar a écrit :
> I'm a bit confused about what is specifically proposed here:
> - Is the suggestion to limit tuples to >1 elements? *This* I'm against
> for practical as well as completeness reasons. Andrei already provided
> one example, and another would be a proper unit type. e.g.
> void foo(int a) {}
> void bar (int b) { return foo(b); }
> - Is the suggestion to allow implicit conversion between (T) and T?
> This brings almost no benefit - (you save two keystrokes?) and adds a
> special case to the language. The added complexity really does not
> justify this.

In fact, they don't need to unpack only for 1 element tuples, but this is the tricky case. Today, tuples auto unpack on function call for instance :

auto t = tuple (1, 2);
foo(t); // call foo(int, int)