September 25, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On 2012-09-25 00:28, bearophile wrote: > (||) > (|1|) > (|1, 2|) > (|1, 2, 3|) What about: || |1| |1, 2| -- /Jacob Carlborg |
September 25, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Philippe Sigaud | 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 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to ixid | 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 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to foobar | 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)
|
Copyright © 1999-2021 by the D Language Foundation