www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP32: Uniform tuple syntax

reply kenji hara <k.hara.pg gmail.com> writes:
http://wiki.dlang.org/DIP32

Kenji Hara
Mar 29 2013
next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Friday, 29 March 2013 at 08:58:06 UTC, kenji hara wrote:

 http://wiki.dlang.org/DIP32

 Kenji Hara


Can't tell at the first read about possible issues, but 
conceptually - love it, fits nicely.
Mar 29 2013
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
29-Mar-2013 12:57, kenji hara пишет:

 http://wiki.dlang.org/DIP32

 Kenji Hara


A few typos like:
{c, $} = tup;   // Rewritten as: a = tup[0];
where it should be //Rewritten as c = tup[0];

About swapping values by tuple assignment.

Why not simply make this work:
{x, y} = {y, x}

By lowering
{x, y}  = {y, x};
to
auto temp0 = y;
auto temp1 = x;
x = temp0;
y = temp1;

And let the compiler do value propagation to remove the extra temp0.

Another note - is there any way to extend this notation to common 
structs other then .tupleof ? I think we may hopefully extended it later 
towards struct destructruing a-la EcmaScript 6, see

http://wiki.ecmascript.org/doku.php?id=harmony:destructuring

All in all it's a great proposal, I'm loving it.


-- 
Dmitry Olshansky
Mar 29 2013
next sibling parent kenji hara <k.hara.pg gmail.com> writes:
2013/3/29 Dmitry Olshansky <dmitry.olsh gmail.com>


 A few typos like:
 {c, $} = tup;   // Rewritten as: a = tup[0];
 where it should be //Rewritten as c = tup[0];


Thanks. Fixed.



 About swapping values by tuple assignment.

 Why not simply make this work:
 {x, y} = {y, x}

 By lowering
 {x, y}  = {y, x};
 to
 auto temp0 = y;
 auto temp1 = x;
 x = temp0;
 y = temp1;

 And let the compiler do value propagation to remove the extra temp0.


Because it already exists.

template Seq(T...) { alias Seq = T; }
void main()
{
    int x = 1, y = 2;
    Seq!(x, y) = Seq!(y, x);    // tuple assigmnent
    assert(x == 2);
    assert(y == 2);
}

Another note - is there any way to extend this notation to common structs

 other then .tupleof ? I think we may hopefully extended it later towards
 struct destructruing a-la EcmaScript 6, see

 http://wiki.ecmascript.org/**doku.php?id=harmony:**destructuring<http://wiki.ecmascript.org/doku.php?id=harmony:destructuring>



Hmm, interesting. I'll see it later.

Kenji Hara
Mar 29 2013
prev sibling parent "angel" <andrey.gelman gmail.com> writes:
Another reason to allow swapping values ( {a, b} = {b, a} ) is 
nice parallel semantics that might provide cool features on some 
future (or niche) parallel hardware.
Think of
{a, b} = {funcA(), funcB()};
Parallel semantics is able to evolve to parallel execution, which 
is one cool feature.
In Go language it is so.
Mar 29 2013
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
My first thought when I saw {} was json. This is getting a little 
further away from tuples, but would it be hard to add named 
fields to this too like json:

auto a = {"foo":12, "bar":"twelve"};

int a_foo = a.foo;
string a_bar = a[1];


The std.typecons Tuple!() can do this kind of thing too.
Mar 29 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 auto a = {"foo":12, "bar":"twelve"};

 int a_foo = a.foo;
 string a_bar = a[1];


 The std.typecons Tuple!() can do this kind of thing too.


I think Tuple!() has them mostly because there is no handy syntax 
to unpack them.

Tuples with field names are records.

Bye,
bearophile
Mar 29 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/29/2013 01:49 PM, Adam D. Ruppe wrote:

 My first thought when I saw {} was json. This is getting a little
 further away from tuples, but would it be hard to add named fields to
 this too like json:

 auto a = {"foo":12, "bar":"twelve"};

 int a_foo = a.foo;
 string a_bar = a[1];


 The std.typecons Tuple!() can do this kind of thing too.


Remove the quotes and it looks like a struct literal.

I think if named fields are allowed, it should look as follows:

auto a = {foo: 12, bar: "twelve"};
Mar 29 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-03-29 14:26, Timon Gehr wrote:


 Remove the quotes and it looks like a struct literal.

 I think if named fields are allowed, it should look as follows:

 auto a = {foo: 12, bar: "twelve"};


I agree.

-- 
/Jacob Carlborg
Mar 29 2013
prev sibling next sibling parent reply kenji hara <k.hara.pg gmail.com> writes:
For tuple values with named fields, we need more thoughts about semantics.

alias MyPair = typeof({1, "hi"});
alias MyRecord = typeof({count:1, msg:"hi"});
static assert(is(MyPair == MyRecord));  // true or false?
static assert(is(MyPair  : MyRecord));  // true or false?
static assert(is(MyRecord  : MyPair));  // true or false?
alias MyStudent = typeof({num:1, name:"John"});
static assert(is(MyRecord == MyStudent));  // true or false?

Kenji Hara


2013/3/29 Adam D. Ruppe <destructionator gmail.com>


 My first thought when I saw {} was json. This is getting a little further
 away from tuples, but would it be hard to add named fields to this too like
 json:

 auto a = {"foo":12, "bar":"twelve"};

 int a_foo = a.foo;
 string a_bar = a[1];


 The std.typecons Tuple!() can do this kind of thing too.
Mar 29 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
On Friday, 29 March 2013 at 14:57:33 UTC, kenji hara wrote:

 For tuple values with named fields, we need more thoughts about 
 semantics.


Tuples with named fields are records. Once we have a unpacking 
syntax, the names become less needed. I suggest to leave field 
names to the Stage2.

Bye,
bearophile
Mar 29 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
kenji hara:


 For tuple values with named fields, we need more thoughts about 
 semantics.

 alias MyPair = typeof({1, "hi"});
 alias MyRecord = typeof({count:1, msg:"hi"});
 static assert(is(MyPair == MyRecord));  // true or false?
 static assert(is(MyPair  : MyRecord));  // true or false?
 static assert(is(MyRecord  : MyPair));  // true or false?
 alias MyStudent = typeof({num:1, name:"John"});
 static assert(is(MyRecord == MyStudent));  // true or false?


One solution:
http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29

{count:1, "hi"} and {1, msg:"hi"} are invariant.

{count:1, msg:"hi"}, {count:1, "hi"} and {1, msg:"hi"} are 
covariant to {1, "hi"}.

But I think it's better to leave this to the Stage2.

Bye,
bearophile
Mar 29 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-03-29 13:49, Adam D. Ruppe wrote:

 My first thought when I saw {} was json. This is getting a little
 further away from tuples, but would it be hard to add named fields to
 this too like json:

 auto a = {"foo":12, "bar":"twelve"};

 int a_foo = a.foo;
 string a_bar = a[1];


I had a proposal of anonymous structs that is similar to this:

http://forum.dlang.org/thread/kfbnuc$1cro$1 digitalmars.com

-- 
/Jacob Carlborg
Mar 29 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
kenji hara:


 http://wiki.dlang.org/DIP32


Thank you Kenji for working on this :-)

Some comments on your proposal:

- - - - - - - - - - - -


 Use braces and commas. Inside tuple literal, ; never appears. 
 So it will not be confused with lambdas and ScopeStatements.<


This is true. On the other hand it's not too much hard to forget 
a ; or to not see it by mistake. So please let's think well about 
this important design decision.

- - - - - - - - - - - -

I presume this will be valid code:

auto tup = {10, "hi", 3.14};
assert(tup[0..2] == {10, "hi"});

- - - - - - - - - - - -

One handy tuple syntax in Haskell allows you to name both the 
items of a tuple and it whole:


void foo(t2 {int a, string b}) {
    // here a and b are tuple items and t2 is the whole tuple.
}
auto t1 {x, y} = {10, "hi"};
foo(t1);

- - - - - - - - - - - -

auto tup = {};  // zero-element tuple (Syntax meaning will be 
changed!)


Nullary tuples are not that useful in D. Scala doesn't even have 
a short literal for them.

So a longer syntax like this is acceptable:

auto tup = Tuple();

- - - - - - - - - - - -

This is nice, so we are merging tuple types with tuples, this 
will simplify D language:

// declare tuple value by using explicit tuple type
{int, string} tup = {1, "hi"};

  alias TL = {int, string[], double[string]};  // types


But one thing to remember in the document is that here T1 and T2 
are different, because your tuples do not auto-flatten as 
TypeTuples currently do:

alias T1 = {float, double, real};
alias T2 = {float, double, {real}};

- - - - - - - - - - - -

foreach (Float; {float, double, real}) { ... }

I think you meant to put a variable name there.

- - - - - - - - - - - -

     {1}         // one-element tuple

I presume this too will be accepted as 1-tuple:

     {1,}

- - - - - - - - - - - -

{c, $} = tup;   // Rewritten as: c = tup[0];

$ is used for array lengths, so it's not so good to overload it 
to mean "don't care" too.


Alternative syntaxes:

{c, $_} = tup;
{c,  } = tup;
{c,  _} = tup;
{c, $$} = tup;
{c, {}} = tup;
{c, {_}} = tup;
{c, $~} = tup;
{c,  ~= tup;
etc.

- - - - - - - - - - - -

if (auto {1, y} = tup) {
     // If the first element of tup (tup[0]) is equal to 1,
     // y captures the second element of tup (tup[1]).
}


I suggest to leave that pattern matching plus conditional to a 
future refinement of tuple implementation (a second stage. And 
remove it from this first stage proposal. So I suggest to split 
your proposal in two successive proposals). It seems handy, but D 
programmers need some time to go there.

- - - - - - - - - - - -

switch (tup) {
     case {1, 2}:
     case {$, 2}:
     case {1, x}:    // capture tup[1] into 'x' when tup[0] == 1
     default:        // same as {...}
}


What's quite important here is the "final switch". D has to make 
sure you are considering all possible cases.

- - - - - - - - - - - -

I suggest to leave this to the second stage, and remove it from 
this proposal:

auto tup = {1, "hi", 3.14, [1,2,3]};
if (auto {1, "hi", ...} = tup) {}

- - - - - - - - - - - -

"will" is written badly:

// If the first element of coord is equal to 1 (== x), 'then' 
statement wil be evaluated.


- - - - - - - - - - - -

I think this is the third thing to leave to the second stage:


int x = 1;
if (auto {$x, y} = coord) { ... }

- - - - - - - - - - - -

This is nice:

if (auto {x, y} = coord[]) {}   // same, explicitly expands fields

- - - - - - - - - - - -

This is handy and it's vaguely present in Python3, but I suggest 
to leave this (4th thing) to the second stage:

if (auto {num, msg, ...} = tup) {}      // ok, `...` matches to 
zero-elements.

- - - - - - - - - - - -

Bye,
bearophile
Mar 29 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
 {c, {}} = tup;


This can't be used, because having an empty tuple as second tuple 
item is valid.



 {c,  ~= tup;


That was:

{c,  ~} tup;

Bye,
bearophile
Mar 29 2013
prev sibling next sibling parent reply =?utf-8?Q?Simen_Kj=C3=A6r=C3=A5s?= <simen.kjaras gmail.com> writes:
On Fri, 29 Mar 2013 13:56:08 +0100, bearophile <bearophileHUGS lycos.com>  
wrote:


 One handy tuple syntax in Haskell allows you to name both the items of a  
 tuple and it whole:


 void foo(t2 {int a, string b}) {
     // here a and b are tuple items and t2 is the whole tuple.
 }
 auto t1 {x, y} = {10, "hi"};
 foo(t1);


I suggest instead this syntax:

auto {x, y} t1 = {10, "hi"};

It's closer to regular D syntax.



 foreach (Float; {float, double, real}) { ... }

 I think you meant to put a variable name there.


foreach (Type; {float, double, real}) { ... }

See it now?



 - - - - - - - - - - - -

 {c, $} = tup;   // Rewritten as: c = tup[0];

 $ is used for array lengths, so it's not so good to overload it to mean  
 "don't care" too.

 Alternative syntaxes:

 {c, $_} = tup;
 {c,  } = tup;
 {c,  _} = tup;
 {c, $$} = tup;
 {c, {}} = tup;
 {c, {_}} = tup;
 {c, $~} = tup;
 {c,  ~= tup;
 etc.


... has been introduced to match zero or more elements for pattern matching
already. I see no reason not to use ... for this.

-- 
Simen
Mar 29 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Simen Kjærås:


 void foo(t2 {int a, string b}) {
    // here a and b are tuple items and t2 is the whole tuple.
 }
 auto t1 {x, y} = {10, "hi"};
 foo(t1);


 I suggest instead this syntax:

 auto {x, y} t1 = {10, "hi"};

 It's closer to regular D syntax.


But I'd like sometime to tie t1 to that {}, to help my eyes.




 {c, $_} = tup;
 {c,  } = tup;
 {c,  _} = tup;
 {c, $$} = tup;
 ...
 {c, {_}} = tup;
 {c, $~} = tup;
 ...
 etc.


 ... has been introduced to match zero or more elements for 
 pattern matching
 already. I see no reason not to use ... for this.


Telling the language that there there is exactly one item to 
match on, that you don't care of, is important. The "..." syntax 
can't tell apart the case for zero, one, or more items. So "..." 
can't be enough here.

Bye,
bearophile
Mar 29 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/29/2013 02:17 PM, Simen Kjærås wrote:

 On Fri, 29 Mar 2013 13:56:08 +0100, bearophile
 <bearophileHUGS lycos.com> wrote:


 One handy tuple syntax in Haskell allows you to name both the items of
 a tuple and it whole:


 void foo(t2 {int a, string b}) {
     // here a and b are tuple items and t2 is the whole tuple.
 }
 auto t1 {x, y} = {10, "hi"};
 foo(t1);


 I suggest instead this syntax:

 auto {x, y} t1 = {10, "hi"};

 It's closer to regular D syntax.
 ...


It is already taken and equivalent to:

{x, y} t1 = {10, "hi"};
Mar 29 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/29/2013 01:56 PM, bearophile wrote:

 kenji hara:


 ...
 Use braces and commas. Inside tuple literal, ; never appears. So it
 will not be confused with lambdas and ScopeStatements.<


 This is true. ...


It is false.
Mar 29 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Once tuples have a built-in syntax it becomes possible to add 
pairs/byPair to associative arrays:


auto aa = [1:2, 3:4];
{int, int}[] myPairs1 = aa.pairs;
foreach ({k, v}; myPairs1) {}
auto myPairs2 = aa.byPair;
foreach ({k, v}; myPairs2) {}

Bye,
bearophile
Mar 29 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
2013/3/29 bearophile <bearophileHUGS lycos.com>


 One handy tuple syntax in Haskell allows you to name both the items of a
 tuple and it whole:

 void foo(t2 {int a, string b}) {
    // here a and b are tuple items and t2 is the whole tuple.
 }
 auto t1 {x, y} = {10, "hi"};
 foo(t1);


It will introduce a kind of "reference variable" to D.

auto t1 {x, y} = {10, "hi"};
assert(&t1[0] == &x);
// t1[0] and x may refer same address on stack.

Such case, you can repeat pack and unpack.

void foo({int a, string b}) {
   // auto t2 = {a, b};  // make tuple by copy, or
   // {a, b} = {1, 2};    // make pack and use it immediately
}
auto {x, y} = {10, "hi"};  foo({x, y});



 auto tup = {};  // zero-element tuple (Syntax meaning will be changed!)

 Nullary tuples are not that useful in D. Scala doesn't even have a short
 literal for them.

 So a longer syntax like this is acceptable:

 auto tup = Tuple();


This is for the consistency of language elements.
If you want to zero-parameter lambda, you can write like follows.

auto fn = (){};
auto fn = {;};



 - - - - - - - - - - - -

 This is nice, so we are merging tuple types with tuples, this will
 simplify D language:

 // declare tuple value by using explicit tuple type
 {int, string} tup = {1, "hi"};

  alias TL = {int, string[], double[string]};  // types


 But one thing to remember in the document is that here T1 and T2 are
 different, because your tuples do not auto-flatten as TypeTuples currently
 do:

 alias T1 = {float, double, real};
 alias T2 = {float, double, {real}};


It would need more description. I'll explain about that.

- - - - - - - - - - - -

 foreach (Float; {float, double, real}) { ... }

 I think you meant to put a variable name there.


Float is the iterated type.



 - - - - - - - - - - - -

     {1}         // one-element tuple

 I presume this too will be accepted as 1-tuple:

     {1,}


Currently D allows redundant commas in some places.
void foo(int x, int y,) {}
enum E { a = 1, b = 2, }
auto arr = [1,2,3,];

So, compiler would accept following tuples.

auto tup = {1,};
auto tup = {1,"hi",};



 - - - - - - - - - - - -

 {c, $} = tup;   // Rewritten as: c = tup[0];

 $ is used for array lengths, so it's not so good to overload it to mean
 "don't care" too.

 Alternative syntaxes:

 {c, $_} = tup;
 {c,  } = tup;
 {c,  _} = tup;
 {c, $$} = tup;
 {c, {}} = tup;
 {c, {_}} = tup;
 {c, $~} = tup;
 {c,  ~= tup;
 etc.


Placeholder token is debatable.



 - - - - - - - - - - - -


 if (auto {1, y} = tup) {
     // If the first element of tup (tup[0]) is equal to 1,
     // y captures the second element of tup (tup[1]).
 }


 I suggest to leave that pattern matching plus conditional to a future
 refinement of tuple implementation (a second stage. And remove it from this
 first stage proposal. So I suggest to split your proposal in two successive
 proposals). It seems handy, but D programmers need some time to go there.


For complex tuple unpacking requires the part of pattern matching.

auto tup = {1, {2,3,4,5,6}}
auto {x, {$, y, ...}} = tup;   // makes nested tuple pattern for unpacking
assert(x == 1);
assert(y == 3);

So I'd like to keep one DIP.



 - - - - - - - - - - - -

 switch (tup) {
     case {1, 2}:
     case {$, 2}:
     case {1, x}:    // capture tup[1] into 'x' when tup[0] == 1
     default:        // same as {...}
 }


 What's quite important here is the "final switch". D has to make sure you
 are considering all possible cases.

 - - - - - - - - - - - -

 I suggest to leave this to the second stage, and remove it from this
 proposal:

 auto tup = {1, "hi", 3.14, [1,2,3]};
 if (auto {1, "hi", ...} = tup) {}

 - - - - - - - - - - - -

 "will" is written badly:


 // If the first element of coord is equal to 1 (== x), 'then' statement
 wil be evaluated.


Will fix.



 - - - - - - - - - - - -

 I think this is the third thing to leave to the second stage:

 int x = 1;
 if (auto {$x, y} = coord) { ... }

 - - - - - - - - - - - -

 This is nice:

 if (auto {x, y} = coord[]) {}   // same, explicitly expands fields

 - - - - - - - - - - - -

 This is handy and it's vaguely present in Python3, but I suggest to leave
 this (4th thing) to the second stage:

 if (auto {num, msg, ...} = tup) {}      // ok, `...` matches to
 zero-elements.


Kenji Hara
Mar 29 2013
prev sibling parent reply "Zach the Mystic" <reachzach gggggmail.com> writes:
On Friday, 29 March 2013 at 12:56:10 UTC, bearophile wrote:

 $ is used for array lengths, so it's not so good to overload it 
 to mean "don't care" too.

 Alternative syntaxes:

 {c, $_} = tup;
 {c,  } = tup;
 {c,  _} = tup;
 {c, $$} = tup;
 {c, {}} = tup;
 {c, {_}} = tup;
 {c, $~} = tup;
 {c,  ~= tup;
 etc.


{c, ?} = tup;
Mar 30 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Zach the Mystic:


 {c, $_} = tup;
 {c,  } = tup;
 {c,  _} = tup;
 {c, $$} = tup;
 {c, {}} = tup;
 {c, {_}} = tup;
 {c, $~} = tup;
 {c,  ~= tup;
 etc.


 {c, ?} = tup;


Right, I was forgetting that.
Or this if you want to keep the single "?" for hypothetical 
future nullable types:

{c, ?_} = tup;

Bye,
bearophile
Mar 30 2013
parent reply "timotheecour" <timothee.cour2 gmail.com> writes:
On Saturday, 30 March 2013 at 18:05:27 UTC, bearophile wrote:

 Zach the Mystic:


 {c, $_} = tup;
 {c,  } = tup;
 {c,  _} = tup;
 {c, $$} = tup;
 {c, {}} = tup;
 {c, {_}} = tup;
 {c, $~} = tup;
 {c,  ~= tup;
 etc.


 {c, ?} = tup;


 Right, I was forgetting that.
 Or this if you want to keep the single "?" for hypothetical 
 future nullable types:

 {c, ?_} = tup;



What about
----
{c, void} = tup;
----
(proposed by Hara Kenji in the original AutoTupleDeclaration 
declaration pull request  
https://github.com/D-Programming-Language/dmd/pull/341 )

(and, independently of the missing symbol choice)
----
{a,b,void...} = tup; //tup = {1,2,3,4,5};
----
Apr 05 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
timotheecour:


 What about
 ----
 {c, void} = tup;


I think the question mark is better here. It's shorter and it has 
only one meaning.

Bye,
bearophile
Apr 05 2013
parent reply "Zach the Mystic" <reachzach gggggmail.com> writes:
On Friday, 5 April 2013 at 23:49:49 UTC, bearophile wrote:

 timotheecour:


 What about
 ----
 {c, void} = tup;


 I think the question mark is better here. It's shorter and it 
 has only one meaning.

 Bye,
 bearophile


Not disagreeing, but you had mentioned nullable types before, and 
I was wondering what they might look like also. Have you made an 
enhancement for these I could examine?
Apr 05 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Zach the Mystic:


 Not disagreeing, but you had mentioned nullable types before, 
 and I was wondering what they might look like also. Have you 
 made an enhancement for these I could examine?


I opened this:
http://d.puremagic.com/issues/show_bug.cgi?id=4571

Part of the syntax is:

T? means T nullable
T  = means not nullable.

But that ER is a confused mess, and in the meantime the  disable 
was introduced. Now the probability of such nullable 
syntax+semantics to be introduced in D is very low, so probably I 
will close down that ER.

Bye,
bearophile
Apr 06 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/6/13 4:10 AM, bearophile wrote:

 Zach the Mystic:


 Not disagreeing, but you had mentioned nullable types before, and I
 was wondering what they might look like also. Have you made an
 enhancement for these I could examine?


 I opened this:
 http://d.puremagic.com/issues/show_bug.cgi?id=4571

 Part of the syntax is:

 T? means T nullable
 T  = means not nullable.

 But that ER is a confused mess, and in the meantime the  disable was
 introduced. Now the probability of such nullable syntax+semantics to be
 introduced in D is very low, so probably I will close down that ER.

 Bye,
 bearophile


I think it's safe to close it. Nullable types have not enjoyed a lot of 


Andrei
Apr 06 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 I think it's safe to close it. Nullable types have not enjoyed 



On the other hand they have gained appreciation in almost every 

Java-Like languages running on the JavaVM, so this is a not small 
failure point of D. I think all type-rich languages that will be 
designed in future will have nonnullable typing. D is  old-school 
on this.

Bye,
bearophile
Apr 06 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 6 April 2013 at 12:59:53 UTC, bearophile wrote:

 Andrei Alexandrescu:


 I think it's safe to close it. Nullable types have not enjoyed 



 On the other hand they have gained appreciation in almost every 

 Java-Like languages running on the JavaVM, so this is a not 
 small failure point of D. I think all type-rich languages that 
 will be designed in future will have nonnullable typing. D is  
 old-school on this.


Non nullable should be the default. Compiler know know how to 
track initialization.
Apr 06 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 6 April 2013 at 12:41:46 UTC, Andrei Alexandrescu 
wrote:

 On 4/6/13 4:10 AM, bearophile wrote:

 Zach the Mystic:


 Not disagreeing, but you had mentioned nullable types before, 
 and I
 was wondering what they might look like also. Have you made an
 enhancement for these I could examine?


 I opened this:
 http://d.puremagic.com/issues/show_bug.cgi?id=4571

 Part of the syntax is:

 T? means T nullable
 T  = means not nullable.

 But that ER is a confused mess, and in the meantime the 
  disable was
 introduced. Now the probability of such nullable 
 syntax+semantics to be
 introduced in D is very low, so probably I will close down 
 that ER.

 Bye,
 bearophile


 I think it's safe to close it. Nullable types have not enjoyed 


 Andrei



really useful.

In D, this is implementable as a lib anyway.
Apr 06 2013