View mode: basic / threaded / horizontal-split · Log in · Help
September 28, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 27/09/2012 08:17, Jacob Carlborg a écrit :
> On 2012-09-27 00:38, bearophile wrote:
>
>> I have appreciated named fields of D tuples since the beginning, I have
>> found them quite handy. With them sometimes you don't need to unpack a
>> tuple, you can just access its fields with a nice name, avoiding to move
>> around more than one variable.
>
> If you could do something like this:
>
> auto x, y = tuple(1, 2);
>
> Wouldn't that be an acceptable solution instead?
>

It is ambiguous with the comma declaration syntax.
September 29, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-28 19:09, deadalnix wrote:

> It is ambiguous with the comma declaration syntax.

I could live without it.

-- 
/Jacob Carlborg
October 06, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei Alexandrescu 
wrote:
> I discussed this with Walter, and we concluded that we could 
> deprecate the comma operator if it helps tuples. So I started 
> with this:
>
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
>
> Unfortunately, I started much cockier than I ended. The 
> analysis in there fails to construct a case even half strong 
> that deprecating the comma operator could significantly help 
> tuples. Well it essentially concludes that tuples are mostly 
> fine as they are, and attempts to embellish them syntactically 
> are marred with unexpected problems. Nevertheless, I sure have 
> missed aspects all over, so contributions are appreciated.
>
>
> Thanks,
>
> Andrei

With removed comma operator from D next code will work?

module maybe;

import std.stdio;
import std.algorithm;

R  With(I, R)(I o, R function (I) fun)
{
	return o is null ? null : fun(o);
}

R Return(I, R)(I o, R function (I) fun, R failureResult)
{
	return o is null ? failureResult : fun(o);
}

I If(I)(I o, bool function (I) fun)
{
	return o is null ? null : fun(o) ? o : null;
}

I Unless(I)(I o, bool function (I) fun)
{
	return o is null ? null : fun(o) ? null : o;
}

I Do(I)(I o, void function (I) fun)
{
	return o is null ? null : fun(o), o;
}

void doit(string value)
{
	writeln("Loading... \n");
}


void main()
{
	string name = "D";

	name = name.With((string x) => "Hello, " ~ x ~ "!").
				If((string x) => canFind(x, "D")).
				Do((string x) => x.doit).
				Return((string x) => x ~ " I love You!", "Oh, my!");
	
	writeln(name);
}


especially template function

I Do(I)(I o, void function (I) fun)
{
	return o is null ? null : fun(o), o;
}
October 06, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 11:55 AM, Caligo wrote:
> If tuples are ever introduced, I hope parentheses will not be used.
>
> I would prefer something like this:
>
> tuple<2,1,8>

Not using parentheses: a possibly valid idea!

Using angle brackets: never going to happen.

People HATE angle brackets.  There is extremely good justification for 
this hatred, because C++ already stepped on that landmine and suffered 
dearly for it.

If you were to use angle brackets, then I would try to do this:
tuple<a>b,c> d
Which way should this be parsed?
It might be a value tuple of type <bool,bool>
or it might be a declaration: d is of type <bool, typeof(c)>

It is very easy to create cases with angle brackets that are 
syntactically ambiguous and make it impossible to parse code as a 
context-free-grammar.  It is harder, but probably possible, to create 
cases where such a syntax is also completely ambiguous semantically too.
October 06, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/23/2012 04:40 PM, Andrei Alexandrescu wrote:
> I discussed this with Walter, and we concluded that we could deprecate
> the comma operator if it helps tuples. So I started with this:
>
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
>
> Unfortunately, I started much cockier than I ended. The analysis in
> there fails to construct a case even half strong that deprecating the
> comma operator could significantly help tuples. Well it essentially
> concludes that tuples are mostly fine as they are, and attempts to
> embellish them syntactically are marred with unexpected problems.
> Nevertheless, I sure have missed aspects all over, so contributions are
> appreciated.
>
>
> Thanks,
>
> Andrei

Might some of the ambiguity be reduced by defining special tokens for 
dereferencing tuple elements?

(int[]) a = ([1,2,3]);
assert(a[0]   == 1);
assert(a[[0]] == [1,2,3]);

I suspect that this would allow us to indulge in the attractive notion 
of single-element tuples.

Would the addition of such a token be considered heresy?
Next ›   Last »
13 14 15 16 17
Top | Discussion index | About this forum | D home