www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The stately := operator feature proposal

reply "MrzlganeE" <bulletproofchest gmail.com> writes:
Hi,

Please consider a request for just one piece of syntax sugar in D.

In places where I write a bunch of short mathy code, I do not 
want to use 'auto'. The := operator would allow to declare a 
variable, deduce its type, and define its value.

void main() {
     x := 1;
     y := 2.0;
     z := x * y;
     y = 3.0;
}

I do not want to see the word 'auto', because it has little to do 
with the problem I am expressing. I find it distracting. 'auto' 
suggests D's type system -- but I am just thinking of the 
algorithm. I want to see less words about the type system, and 
focus my eyes on the problem that I am solving.

I realize that D is not about syntax sugar, but this is different:

- It is easily understood by computer scientists, and 
mathematicians coming from many different backgrounds -- it's not 
obscure like a perl syntax construct.

- I would not write 'auto' while expressing an algorithm on a 
whiteboard. But I may very well write :=

- It has a historical record of use in old BNF-grammar languages.

- I think people would really *use* it, where they don't want to 
use auto today.

- It's not 'un-C-like' -- it is only not-like-C, because C didn't 
support the feature. It is actually a natural fit!

     for (i := 0; i < 24; i++) {
     }

- It is very easily remembered: If you've seen it once, you know 
it.

Today, I would rather write 'double y = 2.0;' than 'auto y = 2.0;'
But := would change that.

Please consider it.

- MrzlganeE
May 29 2013
next sibling parent reply "Diggory" <diggsey googlemail.com> writes:
On Thursday, 30 May 2013 at 00:20:00 UTC, MrzlganeE wrote:

 Hi,

 Please consider a request for just one piece of syntax sugar in 
 D.

 In places where I write a bunch of short mathy code, I do not 
 want to use 'auto'. The := operator would allow to declare a 
 variable, deduce its type, and define its value.

 void main() {
     x := 1;
     y := 2.0;
     z := x * y;
     y = 3.0;
 }

 I do not want to see the word 'auto', because it has little to 
 do with the problem I am expressing. I find it distracting. 
 'auto' suggests D's type system -- but I am just thinking of 
 the algorithm. I want to see less words about the type system, 
 and focus my eyes on the problem that I am solving.

 I realize that D is not about syntax sugar, but this is 
 different:

 - It is easily understood by computer scientists, and 
 mathematicians coming from many different backgrounds -- it's 
 not obscure like a perl syntax construct.

 - I would not write 'auto' while expressing an algorithm on a 
 whiteboard. But I may very well write :=

 - It has a historical record of use in old BNF-grammar 
 languages.

 - I think people would really *use* it, where they don't want 
 to use auto today.

 - It's not 'un-C-like' -- it is only not-like-C, because C 
 didn't support the feature. It is actually a natural fit!

     for (i := 0; i < 24; i++) {
     }

 - It is very easily remembered: If you've seen it once, you 
 know it.

 Today, I would rather write 'double y = 2.0;' than 'auto y = 
 2.0;'
 But := would change that.

 Please consider it.

 - MrzlganeE



You can do this:

template Math(string code) {
     enum Math = transform(code); // Do whatever CTFE transforms 
you want
}

mixin Math!q{
     x := 1;
     y := 2;

     writeln(x*y);
};

Although it will be a lot easier when std.regex works at compile 
time...
May 29 2013
parent reply "MrzlganeE" <bulletproofchest gmail.com> writes:
Diggory:  That's very cool -- being able to do that in D. Thanks 
for showing me :)

But it is not even a remotely practical solution.
     The idea is to write less, and so the solution you've given 
is to write more mixins all over the place. I said I don't even 
want to write 'auto', I am surely not writing the big mixin chunk.

I only gave an example of math stuff.
But I'd use := for the non-math stuff too.

I want := it to be available everywhere.
Even if I am just typing a snippet into dpaste.

If D implements this, C++ will try to copy it 10 years later.
It's a futuristic thing -- what is old is new.
May 29 2013
parent reply "Diggory" <diggsey googlemail.com> writes:
On Thursday, 30 May 2013 at 01:35:58 UTC, MrzlganeE wrote:

 Diggory:  That's very cool -- being able to do that in D. 
 Thanks for showing me :)

 But it is not even a remotely practical solution.
     The idea is to write less, and so the solution you've given 
 is to write more mixins all over the place. I said I don't even 
 want to write 'auto', I am surely not writing the big mixin 
 chunk.

 I only gave an example of math stuff.
 But I'd use := for the non-math stuff too.

 I want := it to be available everywhere.
 Even if I am just typing a snippet into dpaste.

 If D implements this, C++ will try to copy it 10 years later.
 It's a futuristic thing -- what is old is new.


The mixin definition only needs to exist once, and you can use 
"mixin" anywhere - you could wrap an entire source file in it:

mixin!q{

/* All of your code */

}
May 29 2013
next sibling parent reply "Diggory" <diggsey googlemail.com> writes:
On Thursday, 30 May 2013 at 02:51:47 UTC, Diggory wrote:

 On Thursday, 30 May 2013 at 01:35:58 UTC, MrzlganeE wrote:

 Diggory:  That's very cool -- being able to do that in D. 
 Thanks for showing me :)

 But it is not even a remotely practical solution.
    The idea is to write less, and so the solution you've given 
 is to write more mixins all over the place. I said I don't 
 even want to write 'auto', I am surely not writing the big 
 mixin chunk.

 I only gave an example of math stuff.
 But I'd use := for the non-math stuff too.

 I want := it to be available everywhere.
 Even if I am just typing a snippet into dpaste.

 If D implements this, C++ will try to copy it 10 years later.
 It's a futuristic thing -- what is old is new.


 The mixin definition only needs to exist once, and you can use 
 "mixin" anywhere - you could wrap an entire source file in it:

 mixin!q{

 /* All of your code */

 }


*mixin Math!q{ ... };
May 29 2013
parent Timothee Cour <thelastmammoth gmail.com> writes:
mixins make the code more ugly and the error messages' line numbers will
not be in sync with the code, IIRC.
I would like this syntax sugar too.

It's also used in GO, btw.

On Wed, May 29, 2013 at 7:52 PM, Diggory <diggsey googlemail.com> wrote:


 On Thursday, 30 May 2013 at 02:51:47 UTC, Diggory wrote:


 On Thursday, 30 May 2013 at 01:35:58 UTC, MrzlganeE wrote:


 Diggory:  That's very cool -- being able to do that in D. Thanks for
 showing me :)

 But it is not even a remotely practical solution.
    The idea is to write less, and so the solution you've given is to
 write more mixins all over the place. I said I don't even want to write
 'auto', I am surely not writing the big mixin chunk.

 I only gave an example of math stuff.
 But I'd use := for the non-math stuff too.

 I want := it to be available everywhere.
 Even if I am just typing a snippet into dpaste.

 If D implements this, C++ will try to copy it 10 years later.
 It's a futuristic thing -- what is old is new.


 The mixin definition only needs to exist once, and you can use "mixin"
 anywhere - you could wrap an entire source file in it:

 mixin!q{

 /* All of your code */

 }


 *mixin Math!q{ ... };
May 29 2013
prev sibling parent "MrzlganeE" <bulletproofchest gmail.com> writes:
Ok, Diggory, thanks for your consideration. I want to keep the 
code clean and direct, with reliable error messages, with 
consistent output line numbers, with standard semantic highlight 
support in D editors, etc. I do not want to use a level of 
indirection or CTFE all of my code. I would rather write auto 
than have all my code go through CTFE just for one operator. As 
mentioned, I want it available on dpaste too.

I'd just like to say that my intention here specifically is to 
request a feature for the D programming language, that we can all 
use -- it's not just for me and my macro.
May 29 2013
prev sibling next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/29/2013 05:19 PM, MrzlganeE wrote:


 The := operator would allow to declare a variable, deduce
 its type, and define its value.

 void main() {
      x := 1;
      y := 2.0;
      z := x * y;
      y = 3.0;
 }


I like it.

Ali
May 29 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 30.05.2013 07:41, schrieb Ali Çehreli:

 On 05/29/2013 05:19 PM, MrzlganeE wrote:

  > The := operator would allow to declare a variable, deduce
  > its type, and define its value.
  >
  > void main() {
  >      x := 1;
  >      y := 2.0;
  >      z := x * y;
  >      y = 3.0;
  > }

 I like it.

 Ali


It is like is done in Go.
May 29 2013
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 30 May 2013 08:01:09 +0200
schrieb Paulo Pinto <pjmlp progtools.org>:


 Am 30.05.2013 07:41, schrieb Ali =C3=87ehreli:

 On 05/29/2013 05:19 PM, MrzlganeE wrote:

  > The :=3D operator would allow to declare a variable, deduce
  > its type, and define its value.
  >
  > void main() {
  >      x :=3D 1;
  >      y :=3D 2.0;
  >      z :=3D x * y;
  >      y =3D 3.0;
  > }

 I like it.

 Ali


=20
 It is like is done in Go.


I don't mind either. I think at first 'auto' was meant to
shorten long template instance names. This seems like the next
step and it looks elegant. Pascal and Go users would love it :D

--=20
Marco
May 30 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
Don't like it. Makes declaration visually less distinguishable 
from further usage.
May 30 2013
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2013-05-30 at 02:19 +0200, MrzlganeE wrote:
[=E2=80=A6]

 In places where I write a bunch of short mathy code, I do not=20
 want to use 'auto'. The :=3D operator would allow to declare a=20
 variable, deduce its type, and define its value.
=20
 void main() {
      x :=3D 1;
      y :=3D 2.0;
      z :=3D x * y;
      y =3D 3.0;
 }


[=E2=80=A6]

=20
      for (i :=3D 0; i < 24; i++) {
      }


Go does exactly this, and it is good.

Less is more.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 30 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, May 30, 2013 09:43:36 Russel Winder wrote:

 On Thu, 2013-05-30 at 02:19 +0200, MrzlganeE wrote:
 [=E2=80=A6]
=20

 In places where I write a bunch of short mathy code, I do not
 want to use 'auto'. The :=3D operator would allow to declare a
 variable, deduce its type, and define its value.
=20
 void main() {
=20
      x :=3D 1;
      y :=3D 2.0;
      z :=3D x * y;
      y =3D 3.0;
=20
 }


=20
 [=E2=80=A6]
=20

      for (i :=3D 0; i < 24; i++) {
      }


=20
 Go does exactly this, and it is good.
=20
 Less is more.


Less would mean not having this syntax, because it would be adding more=
 to the=20
language and therefore increasing its complexity.

Personally, I don't think think that the extra complication caused by h=
aving=20
another syntax for something that we already have is worth it, regardle=
ss of=20
whether it's aesthetically pleasing or not.

And honestly, I actually think that it would make code _less_ legible. =
Sure,=20
other languages use this syntax, but the difference between =3D and :=3D=
 is minor,=20
and we already have auto. So, this adds no functionality whatsoever.

- Jonathan M Davis
May 30 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/30/2013 10:50 AM, Jonathan M Davis wrote:

 On Thursday, May 30, 2013 09:43:36 Russel Winder wrote:

 On Thu, 2013-05-30 at 02:19 +0200, MrzlganeE wrote:
 […]


 In places where I write a bunch of short mathy code, I do not
 want to use 'auto'. The := operator would allow to declare a
 variable, deduce its type, and define its value.

 void main() {

       x := 1;
       y := 2.0;
       z := x * y;
       y = 3.0;

 }


 […]


       for (i := 0; i < 24; i++) {
       }


 Go does exactly this, and it is good.

 Less is more.


 Less would mean not having this syntax,  because it would be adding more to the
 language and therefore increasing its complexity.


Not noticeably.


 Personally, I don't think think that the extra complication caused by having
 another syntax for something that we already have is worth it, regardless of
 whether it's aesthetically pleasing or not.


The complexity argument is not a strong argument for such a simple 
feature (It takes around 10 minutes to implement in a compiler and 2s to 
learn.), especially given the existing complexity of D.

It simply does not fit nicely into the rest of the D declaration syntax. 
(Which I'd argue is an issue with the C-like syntax of D, but many seem 
to like that.)


 And honestly, I actually think that it would make code _less_ legible.


In my experience, anything that removes excessive verboseness makes the 
code more legible.


 Sure, other languages use this syntax, but the difference between = and := is
minor,


It is noticeable at a glimpse. It's simply a matter of getting 
accustomed to new syntax.


 and we already have auto.  So, this adds no functionality whatsoever.


It adds functionality to the parser.
May 30 2013
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/30/13, Timon Gehr <timon.gehr gmx.ch> wrote:

 It is noticeable at a glimpse. It's simply a matter of getting
 accustomed to new syntax.


This depends on the person viewing the code. Don't forget not all
people have 10/10 vision.
May 30 2013
next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 30 May 2013 at 10:46:54 UTC, Andrej Mitrovic wrote:

 On 5/30/13, Timon Gehr <timon.gehr gmx.ch> wrote:

 It is noticeable at a glimpse. It's simply a matter of getting
 accustomed to new syntax.


 This depends on the person viewing the code. Don't forget not 
 all
 people have 10/10 vision.


It is not only matter of vision. People naturally read from left 
to right and this proposal moves important information about 
statement to the middle of the line.
May 30 2013
parent reply "MrzlganeE" <bulletproofchest gmail.com> writes:
x := 2 / pi*z;
auto x = 2 / pi*z;

z := column(i, x, diag);
auto z = column(i, x, diag);

I don't think it's worth it force all people to write the second 
form, over a theoretical nitpick that the programmer will 
possibly forget how interpret symbols.

To me, 'auto' has a price. The price is a foreign word being 
inserted into my math. It's an invasive term. It ruins the 
beautiful expression.

If you think the programmer is going to forget how to read 
symbols, you should consider both sides: "The programmer might 
forget how to read symbols, but also the programmer will be able 
to write declarative expressions involving just their own terms."

It's not all bad, you see?

I am trying to reach for an expressiveness which allows such a 
simple thing -- writing expressions that involve just my own 
terms: x. 2. pi. z. That's the feature!

And allowing to make expressions with just my own terms is such a 
small change to the language, we are only inches away from that. 
It drives me crazy to be so close.

auto x = 2 / pi*z; is like ketchup in my sushi, every time.

Try to consider that people always oppose every single new thing. 
They would have said the array slices are not C-like enough, and 
that '..' is not in the C language and should not be used. But we 
have that great feature now because somebody decided not to be so 
conservative.
May 30 2013
next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 30 May 2013 at 11:41:34 UTC, MrzlganeE wrote:

 To me, 'auto' has a price. The price is a foreign word being 
 inserted into my math. It's an invasive term. It ruins the 
 beautiful expression.


Please don't pull your math into my programming.
May 30 2013
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 30.05.2013 13:41, schrieb MrzlganeE:

 x := 2 / pi*z;
 auto x = 2 / pi*z;

 z := column(i, x, diag);
 auto z = column(i, x, diag);

 I don't think it's worth it force all people to write the second form,
 over a theoretical nitpick that the programmer will possibly forget how
 interpret symbols.

 To me, 'auto' has a price. The price is a foreign word being inserted
 into my math. It's an invasive term. It ruins the beautiful expression.

 If you think the programmer is going to forget how to read symbols, you
 should consider both sides: "The programmer might forget how to read
 symbols, but also the programmer will be able to write declarative
 expressions involving just their own terms."

 It's not all bad, you see?

 I am trying to reach for an expressiveness which allows such a simple
 thing -- writing expressions that involve just my own terms: x. 2. pi.
 z. That's the feature!

 And allowing to make expressions with just my own terms is such a small
 change to the language, we are only inches away from that. It drives me
 crazy to be so close.

 auto x = 2 / pi*z; is like ketchup in my sushi, every time.

 Try to consider that people always oppose every single new thing. They
 would have said the array slices are not C-like enough, and that '..' is
 not in the C language and should not be used. But we have that great
 feature now because somebody decided not to be so conservative.


I disagree.

Given my Pascal background I have a special liking for ":=", and Go also 
makes use of ":=" in the form you propose.

However D's auto follows the way C++11 has decided for type inference 
which is the crowd that we want to bring to D. And not very different 
from var, also used for the same purpose in many other languages.

Additionally, we should avoid making D into a TIMTOWTDI language.

--
Paulo
May 30 2013
parent reply "MrzlganeE" <bulletproofchest gmail.com> writes:
I hate you all, and with this, I exit the D community

The only reason I was here was I dreamed that I could get a 
couple of features
May 30 2013
next sibling parent "MrzlganeE" <bulletproofchest gmail.com> writes:
Not gonna think about D, I got a big C++ codebase to deal with, a 
lot of work to do. D was just a dream. I will check the D website 
again in 3 years
May 30 2013
prev sibling next sibling parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Thu, 30 May 2013 14:13:00 +0100, MrzlganeE <bulletproofchest gmail.com>  
wrote:


 I hate you all, and with this, I exit the D community

 The only reason I was here was I dreamed that I could get a couple of  
 features


Over-react much?

Bear in mind that everyone posting here is on equal footing and simply  
sharing opinions.  The only people you really need to convince are Walter  
or Andrei, or someone else who is actually influential.. perhaps Don.

You can safely ignore almost everyone else :p

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
May 30 2013
parent reply "MrzlganeE" <bulletproofchest gmail.com> writes:
 Over-react much?

 Bear in mind that everyone posting here is on equal footing and 
 simply sharing opinions.  The only people you really need to 
 convince are Walter or Andrei, or someone else who is actually 
 influential.. perhaps Don.

 You can safely ignore almost everyone else :p

 R



I'm gonna hold out hope here and hope Walter will say Yes

Please Walter
Please Andrei

Let me have the math

Please sir
May 30 2013
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 30 May 2013 at 18:41:13 UTC, MrzlganeE wrote:

 Over-react much?

 Bear in mind that everyone posting here is on equal footing 
 and simply sharing opinions.  The only people you really need 
 to convince are Walter or Andrei, or someone else who is 
 actually influential.. perhaps Don.

 You can safely ignore almost everyone else :p

 R



 I'm gonna hold out hope here and hope Walter will say Yes

 Please Walter
 Please Andrei

 Let me have the math

 Please sir


If you're not trolling, you're making a very good impression of 
someone who is.
May 30 2013
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/30/13, MrzlganeE <bulletproofchest gmail.com> wrote:

 I hate you all, and with this, I exit the D community

 The only reason I was here was I dreamed that I could get a
 couple of features


This is the guy that trolls in #d on freenode under the name of Ndit.
He describes a problem, and then screams how D is so much worse than
other languages because of problem X, offering no backup evidence. And
every day he comes up with some new complaint. I don't think we should
take him seriously at all.
May 30 2013
parent "MrzlganeE" <bulletproofchest gmail.com> writes:
 This is the guy that trolls in #d on freenode under the name of 
 Ndit.
 He describes a problem, and then screams how D is so much worse 
 than
 other languages because of problem X, offering no backup 
 evidence.



I have to uphold truth here because people on the newsgroups can 
believe you without being able to verify if you are telling the 
truth.

I've only been to the #D channel a few times, and I've only 
described a single problem there: (Difficulty static-allocating 
in-class). In a friendly talk I also said: (The gc world-stopping 
can be reorganized).

If you aren't flatly lying, then all you have to do is tell: What 
was the other issue I had? And post a snippet / log of it, or a 
link to a snippet/log. Or just remember what it was. You will not 
be able to do so.
May 30 2013
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2013-05-30 at 15:54 +0200, Andrej Mitrovic wrote:

 On 5/30/13, MrzlganeE <bulletproofchest gmail.com> wrote:

 I hate you all, and with this, I exit the D community

 The only reason I was here was I dreamed that I could get a
 couple of features


=20
 This is the guy that trolls in #d on freenode under the name of Ndit.
 He describes a problem, and then screams how D is so much worse than
 other languages because of problem X, offering no backup evidence. And
 every day he comes up with some new complaint. I don't think we should
 take him seriously at all.


I still like:

	x :=3D 1

for a declaration and initialization with type inference.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 30 2013
next sibling parent "watcher" <watcher watcher.org> writes:
On Thursday, 30 May 2013 at 14:27:13 UTC, Russel Winder wrote:

 On Thu, 2013-05-30 at 15:54 +0200, Andrej Mitrovic wrote:

 On 5/30/13, MrzlganeE <bulletproofchest gmail.com> wrote:

 I hate you all, and with this, I exit the D community

 The only reason I was here was I dreamed that I could get a
 couple of features


 
 This is the guy that trolls in #d on freenode under the name 
 of Ndit.
 He describes a problem, and then screams how D is so much 
 worse than
 other languages because of problem X, offering no backup 
 evidence. And
 every day he comes up with some new complaint. I don't think 
 we should
 take him seriously at all.


 I still like:

 	x := 1

 for a declaration and initialization with type inference.


This proposition is just a killer. Mixing a totally different 
syntactical meaning from modula or pascal into d. I don’t like 
that idea at all.
May 30 2013
prev sibling next sibling parent reply "Byron Heads" <byron.heads gmail.com> writes:
On Thursday, 30 May 2013 at 14:27:13 UTC, Russel Winder wrote:

 On Thu, 2013-05-30 at 15:54 +0200, Andrej Mitrovic wrote:

 On 5/30/13, MrzlganeE <bulletproofchest gmail.com> wrote:

 I hate you all, and with this, I exit the D community

 The only reason I was here was I dreamed that I could get a
 couple of features


 
 This is the guy that trolls in #d on freenode under the name 
 of Ndit.
 He describes a problem, and then screams how D is so much 
 worse than
 other languages because of problem X, offering no backup 
 evidence. And
 every day he comes up with some new complaint. I don't think 
 we should
 take him seriously at all.


 I still like:

 	x := 1

 for a declaration and initialization with type inference.



Could be used for assigning from tuples.

iVal, sVal := returnsIntAndString();

would have to decide on how to handle this
x := 1;
x := y * 7;  // error or assignment?

more of an issue with tuples then single lvalues
May 30 2013
parent reply "Byron Heads" <byron.heads gmail.com> writes:
On Thursday, 30 May 2013 at 14:41:09 UTC, Byron Heads wrote:

 On Thursday, 30 May 2013 at 14:27:13 UTC, Russel Winder wrote:

 I still like:

 	x := 1

 for a declaration and initialization with type inference.



 Could be used for assigning from tuples.

 iVal, sVal := returnsIntAndString();

 would have to decide on how to handle this
 x := 1;
 x := y * 7;  // error or assignment?

 more of an issue with tuples then single lvalues


could also be used without the type inference

int x;
x, string s := returnIntAndString();
------
int wx, wy;
...
wx, wy := window.position;
May 30 2013
parent reply Manu <turkeyman gmail.com> writes:
On 31 May 2013 00:59, Byron Heads <byron.heads gmail.com> wrote:


 On Thursday, 30 May 2013 at 14:41:09 UTC, Byron Heads wrote:


 On Thursday, 30 May 2013 at 14:27:13 UTC, Russel Winder wrote:


 I still like:

         x := 1

 for a declaration and initialization with type inference.



 Could be used for assigning from tuples.

 iVal, sVal := returnsIntAndString();

 would have to decide on how to handle this
 x := 1;
 x := y * 7;  // error or assignment?

 more of an issue with tuples then single lvalues


 could also be used without the type inference

 int x;
 x, string s := returnIntAndString();
 ------
 int wx, wy;
 ...
 wx, wy := window.position;


I've raised the topic of multiple-return-values a whole heap of times. It's
usually shot down because it would create ambiguities in existing syntax.
MRV is super useful, and potentially more efficient too (in an ABI where
MRV can each return in arg registers, can save lots of memory hazards). It
produces a situation where you can return more than a single value from a
leaf function (really handy!).

So, I'm very curious to explore how any new assignment syntax can
interact/support with MRV...
May 30 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Manu:


 I've raised the topic of multiple-return-values a whole heap of 
 times. It's
 usually shot down because it would create ambiguities in 
 existing syntax.


Solving only that small problem is a bad idea. A language meant 
to support some functional programming should be able to support 
tuples well enough. Your problem is a special case of tuple 
usage. Don't you agree?

Bye,
bearophile
May 30 2013
parent reply "Byron Heads" <byron.heads gmail.com> writes:
On Friday, 31 May 2013 at 00:50:56 UTC, bearophile wrote:

 Manu:


 I've raised the topic of multiple-return-values a whole heap 
 of times. It's
 usually shot down because it would create ambiguities in 
 existing syntax.


 Solving only that small problem is a bad idea. A language meant 
 to support some functional programming should be able to 
 support tuples well enough. Your problem is a special case of 
 tuple usage. Don't you agree?

 Bye,
 bearophile


The question is which is more optimal for the MRV style of 
programming

// here the compiler can decide the best way to return the two 
ints,
// probably in two registers, maybe even better for inlining
(int, int) positionMRV() { return 1, 2; }

// here the compiler is making a tuple and returning it may not 
be optimal

for tuples

I agree tuples cover more cases, but maybe hard to optimize for 
MRV.

a side note := could be use to extract tuples as well.

Would be nice if _ was not a valid identifier, could have been 
used it for value skipping:

x, _ := positionMRV(); // only care about x value, optimize away
May 31 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05/31/2013 02:54 PM, Byron Heads wrote:

 ...

 The question is which is more optimal for the MRV style of programming

 // here the compiler can decide the best way to return the two ints,
 // probably in two registers, maybe even better for inlining
 (int, int) positionMRV() { return 1, 2; }

 // here the compiler is making a tuple and returning it may not be optimal


 I agree tuples cover more cases, but maybe hard to optimize for MRV.
 ...


No, this is false.


 a side note := could be use to extract tuples as well.

 Would be nice if _ was not a valid identifier, could have been used it
 for value skipping:

 x, _ := positionMRV(); // only care about x value, optimize away
May 31 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/30/13 10:27 AM, Russel Winder wrote:

 I still like:

 	x := 1

 for a declaration and initialization with type inference.


I like it too, and Go users seem to find it handy.

Andrei
May 30 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/30/13, Russel Winder <russel winder.org.uk> wrote:

 I still like:

 	x := 1

 for a declaration and initialization with type inference.


Well the saying goes, even a broken clock..

Personally I think it's way too late for such a feature. What if you
make a typo and instead of declaring a new shadowed variable you end
up modifying an existing one?

int x;
void main()
{
    auto x = 5;  // so far so good, it's obviously a new variable
}

vs:

int x;
void main()
{
    x := 5;
}

which with a typo becomes:

int x;
void main()
{
    x = 5;
}

Could you easily spot the bug?
May 30 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 30 May 2013 09:13:00 -0400, MrzlganeE <bulletproofchest gmail.com>  
wrote:


 I hate you all, and with this, I exit the D community


I'll answer like I do my 2-year-old when HE throws tantrums.

That's OK, we still love you.

-Steve
May 30 2013
prev sibling next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/30/2013 06:13 AM, MrzlganeE wrote:


 I hate you all


But I liked your idea! :) (I still like you too.)

I had seen the syntax in Robert Griesemer's "Go for C programmers" talk. 
I had no objections when watchinğ the talk and it still seems fine now.

Ali
May 30 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/30/13 9:13 AM, MrzlganeE wrote:

 I hate you all, and with this, I exit the D community


How can one exit what one hasn't entered?


 The only reason I was here was I dreamed that I could get a couple of
 features


You need to understand that this is a common trend among newcomers, and 
that they all want to add a couple of _different_ features.


Andrei
May 30 2013
parent reply "MrzlganeE" <bulletproofchest gmail.com> writes:
The := operator can allow a special behavior,
Declaring+defining multiple values from a single return:

x, y, z := f();

/

auto x = f(), y = f(), z = f();
auto x = f(); auto y = x, z = x;
May 30 2013
parent reply "MrzlganeE" <bulletproofchest gmail.com> writes:
And the alternative:

x, y, z := f(), g(), h();
May 30 2013
parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Thursday, 30 May 2013 at 19:11:10 UTC, MrzlganeE wrote:

 And the alternative:

 x, y, z := f(), g(), h();


Right, now you want to add Python features to D. Why don't you 
design your own language instead ?
Jun 06 2013
parent "seany" <seany uni-bonn.de> writes:
take my vote on both this, and SciD

..

Contact me please, if  SciD is still a project in Hand.
Nov 02 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On 30 May 2013 23:13, MrzlganeE <bulletproofchest gmail.com> wrote:


 I hate you all, and with this, I exit the D community

 The only reason I was here was I dreamed that I could get a couple of
 features


You need to show SOME investment/commitment to the language before anybody
is going to take your proposals seriously.
Have you ever written any D code? Shared it?
May 30 2013
prev sibling parent "Joshua Niehus" <jm.niehus gmail.com> writes:
On Thursday, 30 May 2013 at 13:13:02 UTC, MrzlganeE wrote:

 I hate you all, and with this, I exit the D community


ooo, a sensitive troll...

There was a time when D didn't have the sugary lambda syntax: "=>"
I think that turned out nicely.
(maybe someone already mentioned this in the thread, didn't see 
it)

I'm also in favor of ":="
Jun 05 2013
prev sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Thursday, 30 May 2013 at 11:41:34 UTC, MrzlganeE wrote:


 To me, 'auto' has a price. The price is a foreign word being 
 inserted into my math. It's an invasive term. It ruins the 
 beautiful expression.


And tomorrow, you'll complain that := has a foreign character 
into your math, because everywhere else, you use = and there is 
no reason for the first equal sign to add : in front of it.
Jun 06 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05/30/2013 12:46 PM, Andrej Mitrovic wrote:

 On 5/30/13, Timon Gehr <timon.gehr gmx.ch> wrote:

 It is noticeable at a glimpse. It's simply a matter of getting
 accustomed to new syntax.


 This depends on the person viewing the code. Don't forget not all
 people have 10/10 vision.


Those who don't usually use big enough font sizes anyway.
May 30 2013
prev sibling next sibling parent "MrzlganeE" <bulletproofchest gmail.com> writes:
If the programmer cannot make a distinction between an assignment 
and a declaration operator, there will be a lot of trouble!

You could say, p * q and p = q are not visually distinct. They 
only rely on the difference of an operator to distinguish them.

We can go through countless variations within the language where 
you get your work done every day relying on visually distinct 
elements more subtle than this one.
May 30 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, May 30, 2013 12:38:09 Timon Gehr wrote:

 On 05/30/2013 10:50 AM, Jonathan M Davis wrote:

 Personally, I don't think think that the extra complication caused by
 having another syntax for something that we already have is worth it,
 regardless of whether it's aesthetically pleasing or not.


 
 The complexity argument is not a strong argument for such a simple
 feature (It takes around 10 minutes to implement in a compiler and 2s to
 learn.), especially given the existing complexity of D.


Except that even if the feature doesn't add a lot of complexity by itself, 
each feature you add to the language adds to the total complexity, and it adds 
up. If we were willing to add new features simply because they didn't add much 
complexity, pretty soon, you'd have quite a bit of complexity. New features 
need to add a real benefit to be worth complicating the language yet further. 
And I don't think that this does by a long shot. auto already provides us with 
this functionality. It's just that the syntax for auto doesn't fit the OP's 
tastes.

- Jonathan M Davis
May 30 2013
next sibling parent reply "ixid" <nuaccount gmail.com> writes:
 this functionality. It's just that the syntax for auto doesn't 
 fit the OP's
 tastes.

 - Jonathan M Davis


As in Go this would potentially allow tuple assignments in a way 
that auto does not.

x, string y := awesomeFunction();
May 30 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/30/2013 09:57 PM, ixid wrote:

 this functionality. It's just that the syntax for auto doesn't fit the
 OP's
 tastes.

 - Jonathan M Davis


 As in Go this would potentially allow tuple assignments in a way that
 auto does not.

 x, string y := awesomeFunction();


auto (x, string y) = awesomeFunction();

(There is a pull request for that iirc.)
May 30 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Timon Gehr:


 x, string y := awesomeFunction();


 auto (x, string y) = awesomeFunction();

 (There is a pull request for that iirc.)


At this point I suggest to not add that patch to D because tuples 
need a better rounded design.

Using the last syntax suggested today that becomes:

t{auto x, string y} = awesomeFunction();

Bye,
bearophile
May 30 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05/30/2013 10:28 PM, bearophile wrote:

 Timon Gehr:


 x, string y := awesomeFunction();


 auto (x, string y) = awesomeFunction();

 (There is a pull request for that iirc.)


 At this point I suggest to not add that patch to D because tuples need a
 better rounded design.


I think there is no chance to get a decent design without breaking 
(real) code.


 Using the last syntax suggested today that becomes:

 t{auto x, string y} = awesomeFunction();

 Bye,
 bearophile


Frankly, I don't know who would come up with such a wacky construct when 
designing a language from scratch. I don't think language features that 
suffer from bad language evolution are worth adding.
May 30 2013
prev sibling next sibling parent reply "js.mdnq" <js_adddot+mdng gmail.com> writes:
On Thursday, 30 May 2013 at 19:40:54 UTC, Jonathan M Davis wrote:

 On Thursday, May 30, 2013 12:38:09 Timon Gehr wrote:

 On 05/30/2013 10:50 AM, Jonathan M Davis wrote:

 Personally, I don't think think that the extra complication 
 caused by
 having another syntax for something that we already have is 
 worth it,
 regardless of whether it's aesthetically pleasing or not.


 
 The complexity argument is not a strong argument for such a 
 simple
 feature (It takes around 10 minutes to implement in a compiler 
 and 2s to
 learn.), especially given the existing complexity of D.


 Except that even if the feature doesn't add a lot of complexity 
 by itself,
 each feature you add to the language adds to the total 
 complexity, and it adds
 up. If we were willing to add new features simply because they 
 didn't add much
 complexity, pretty soon, you'd have quite a bit of complexity. 
 New features
 need to add a real benefit to be worth complicating the 
 language yet further.
 And I don't think that this does by a long shot. auto already 
 provides us with
 this functionality. It's just that the syntax for auto doesn't 
 fit the OP's
 tastes.

 - Jonathan M Davis


With that attitude one would never be able to achieve anything 
complex. The goal is not to reduce complexity but to find an 
elegant way to deal with the complexity. If a complex project is 
becoming unmanageable due to the complexity then it is due to the 
project management and not the individual components.

You can't solve complex problems with simple solutions(else they 
would be simple problems). Programming is a complex task and 
requires a more complex, but elegant, solution.

One must ask yourself what ripple effect `:=` would have versus 
what benefit. I see `:=` would provide some obvious reduction of 
visual code complexity while adding very little extra complexity 
to the compiler. The reason being is, at least as originally 
stated, `:=` somewhat a self-contained enhancement affecting 
virtually nothing outside what it specifically does... i.e., 
there are no/little chance for unintended consequences.

I think the issue is that some people think that because they 
won't use it or don't need it that it surely won't benefit anyone 
else(so why go through the extra "complexity" to have a 
feature)... it's a pretty common attitude and somewhat 
egotistical.
May 30 2013
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, May 30, 2013 22:27:35 js.mdnq wrote:

 With that attitude one would never be able to achieve anything
 complex. The goal is not to reduce complexity but to find an
 elegant way to deal with the complexity.


Sure, but what you're talking about is pure syntactic sugar that saves a few 
characters and that's it. And in the process, it makes it so that there's now 
another way to do something that has to be explained to people, and then we'll 
have debates over whether auto or := is better, and it's one more thing that 
we're all going to have to deal with, even if it's relatively minor. And it 
adds _zero_ functionality. It would be one thing if we were talking about a 
fetaure that actually had an objective benefit, but the benefits of this one
are 
purely subjective, and it does exactly the same thing as an existing feature.


 I think the issue is that some people think that because they
 won't use it or don't need it that it surely won't benefit anyone
 else(so why go through the extra "complexity" to have a
 feature)... it's a pretty common attitude and somewhat
 egotistical.


Except that if other people use it, you have to deal with it even if you never 
use it. The idea that adding a feature to the language which only a subset of 
the users will use will not affect all users is just plain false.

- Jonathan M Davis
May 30 2013
prev sibling parent reply "MrzlganeE" <bulletproofchest gmail.com> writes:
 And I don't think that this does by a long shot. auto already 
 provides us with
 this functionality. It's just that the syntax for auto doesn't



I understand what you guys are saying, I agree that not 
everything should be added. But come on,

On a *FEW* things you can support 2 styles.

If you support a few styles on a *few* things, it does not mean 
you have to support everything on all things.

D has features for functional programmers, and byte-level 
programmers too!

In the case where it's a really basic thing that opens up a nice 
level of expressiveness for a different type of programmer, and 
there's no compromise that can bring us both together, it's OK to 
support us both!

Because how can the current 'auto' work for both of us?
How could I ever be happy writing math like that?

The arguments you are making about not adding in every parallel 
idea apply to a really different problem:

Something where the single solution *can* genuinely be worked 
out, *can* genuinely come together for both of us, and the 
language designers know this, and they know better than just 
adding in stuff, and they know that a unified solution is better.

But this is different, it doesn't have that potential for ever 
seeing the unified solution. It's just a small thing, for math 
guys, Come on.
May 30 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, May 30, 2013 22:39:40 MrzlganeE wrote:

 And I don't think that this does by a long shot. auto already
 provides us with
 this functionality. It's just that the syntax for auto doesn't


 
 I understand what you guys are saying, I agree that not
 everything should be added. But come on,
 
 On a *FEW* things you can support 2 styles.
 
 If you support a few styles on a *few* things, it does not mean
 you have to support everything on all things.
 
 D has features for functional programmers, and byte-level
 programmers too!


There is a significant difference between a language feature which adds actual 
functionality and one that's purely syntactic sugar.

- Jonathan M Davis
May 30 2013
parent reply "w0rp" <devw0rp gmail.com> writes:
On Thursday, 30 May 2013 at 20:58:35 UTC, Jonathan M Davis wrote:

 There is a significant difference between a language feature 
 which adds actual
 functionality and one that's purely syntactic sugar.

 - Jonathan M Davis


Plus here, the difference is four characters if you count the 
single space. I think there really isn't any value added to the 
language from this syntax. It's an alternative way to write 
something that is already very short and easy to understand. 
Plus, I think of auto as really just a placeholder, given that 
you don't need auto if you have a qualifier, like so:

const x = 3.4f;
May 30 2013
parent reply "js.mdnq" <js_adddot+mdng gmail.com> writes:
On Thursday, 30 May 2013 at 21:30:18 UTC, w0rp wrote:

 On Thursday, 30 May 2013 at 20:58:35 UTC, Jonathan M Davis 
 wrote:

 There is a significant difference between a language feature 
 which adds actual
 functionality and one that's purely syntactic sugar.

 - Jonathan M Davis


 Plus here, the difference is four characters if you count the 
 single space. I think there really isn't any value added to the 
 language from this syntax. It's an alternative way to write 
 something that is already very short and easy to understand. 
 Plus, I think of auto as really just a placeholder, given that 
 you don't need auto if you have a qualifier, like so:

 const x = 3.4f;


Surely you guys realize that a high level programming language IS 
purely "syntactic sugar". A high level programming language DOES 
NOTHING that can't be done in pure binary... after all, it has to 
be translated one to one in it for the program to run on the cpu.

A high level programming language is to simply life both for 
abstraction AND syntax.

It amazes me that you guys state such things when about 30% of 
any programming language is purely "syntactic sugar"... hell, 
auto is just a "syntactic sugar" keyword that offers no new 
functionality... yet you're ok with that?

A class is just syntactic sugar for a collection of variables... 
whats the use? It makes it easier for the programmer... same with 
auto, same with :=... If you don't realize that then you should 
think about it some more... (sure a class is more useful BUT that 
is besides the point)
May 30 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, May 30, 2013 23:36:09 js.mdnq wrote:

 A class is just syntactic sugar for a collection of variables...
 whats the use? It makes it easier for the programmer... same with
 auto, same with :=... If you don't realize that then you should
 think about it some more... (sure a class is more useful BUT that
 is besides the point)


There are orders of magnitudes of difference between providing a new 
abstraction like a class and simply rewriting

auto i = foo;

as

i := foo;

_All_ it does is save you 4 characters and shift where in the statement the 
piece is that tells the compiler to infer the type.

- Jonathan M Davis
May 30 2013
next sibling parent reply "MrzlganeE" <bulletproofchest gmail.com> writes:
Jonathan:

The feature is not possible to rate in terms of character count.

http://www.etymonline.com/index.php?term=automobile

It removes this French word from math expressions.
May 30 2013
parent reply "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
I don't think this is useful.

At least when I see "auto" in the code I immediately understand 
what's going on, whereas with this proposal I have to double 
check my code to see if it's ":=" or "=".
May 30 2013
parent reply "Tyler Jameson Little" <beatgammit gmail.com> writes:
On Friday, 31 May 2013 at 00:57:33 UTC, Minas Mina wrote:

 I don't think this is useful.

 At least when I see "auto" in the code I immediately understand 
 what's going on, whereas with this proposal I have to double 
 check my code to see if it's ":=" or "=".


First off, I write a _lot_ of Go code, and I _love_ the := there. 
It makes things nice and simple, and it fits nicely into the rest 
of the Go syntax. However, I don't think it belongs in D because 
it changes the flow of the code.

The problem is where type specifiers are expected to go. In D 
(and most other C-like languages), types go before the 
identifiers:

     int x, y, z;

When scanning code, if I see a type identifier, I know it's 
declaring something. I immediately know the scope and all is well.

In Go, types go after the identifiers:

     func example(x, y, z int) {}

This is only broken by var|type, which are completely different 
expressions.

For Go, the := makes perfect sense, because when you read Go 
code, you expect the identifier first, then the type. In D 
however, nothing else (correct me if I'm wrong) has this syntax.

I have no problem with the := syntax, I just think it doesn't 
make syntactic sense. It subtly breaks the idioms of the 
language, all for very little gain.

I would be okay with type blocks, or the presented math {} block 
(which could do all sorts of new and exciting things) because 
that would fit more nicely into the language.

If the OP really wants this, he/she can easily write a 
pre-processor for D code that he/she uses on his/her own personal 
projects. A completely untested regex:

     rsync src compilable-source
     find compilable-source/ -name "*.d" -exec sed -i 
"s/\(\\w+\)\\s*:=/auto \1 =/g" {}+

There, feature done in two lines of shell...
Jun 06 2013
parent "nazriel" <spam dzfl.pl> writes:
On Thursday, 6 June 2013 at 16:06:44 UTC, Tyler Jameson Little 
wrote:

 On Friday, 31 May 2013 at 00:57:33 UTC, Minas Mina wrote:

 I don't think this is useful.

 At least when I see "auto" in the code I immediately 
 understand what's going on, whereas with this proposal I have 
 to double check my code to see if it's ":=" or "=".


 First off, I write a _lot_ of Go code, and I _love_ the := 
 there. It makes things nice and simple, and it fits nicely into 
 the rest of the Go syntax. However, I don't think it belongs in 
 D because it changes the flow of the code.

 The problem is where type specifiers are expected to go. In D 
 (and most other C-like languages), types go before the 
 identifiers:

     int x, y, z;

 When scanning code, if I see a type identifier, I know it's 
 declaring something. I immediately know the scope and all is 
 well.

 In Go, types go after the identifiers:

     func example(x, y, z int) {}

 This is only broken by var|type, which are completely different 
 expressions.

 For Go, the := makes perfect sense, because when you read Go 
 code, you expect the identifier first, then the type. In D 
 however, nothing else (correct me if I'm wrong) has this syntax.

 I have no problem with the := syntax, I just think it doesn't 
 make syntactic sense. It subtly breaks the idioms of the 
 language, all for very little gain.


So maybe =: for D? :P
Naa, just kidding.

 I would be okay with type blocks, or the presented math {} 
 block (which could do all sorts of new and exciting things) 
 because that would fit more nicely into the language.

 If the OP really wants this, he/she can easily write a 
 pre-processor for D code that he/she uses on his/her own 
 personal projects. A completely untested regex:

     rsync src compilable-source
     find compilable-source/ -name "*.d" -exec sed -i 
 "s/\(\\w+\)\\s*:=/auto \1 =/g" {}+

 There, feature done in two lines of shell...


+1

AFAIK Namespace (user with such nickcname) already wrote 
preprocesor for D with syntax candies he likes.

I bet if math guys were so interested in D they would do the same 
at some point.

I personally don't care about that :=. Probably won't use as I am 
already familiar and fine with auto. I believe though that 
letting achieving same thing in different ways will just bring 
troubles.
Jun 06 2013
prev sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 30 May 2013 at 23:50:40 UTC, Jonathan M Davis wrote:

 There are orders of magnitudes of difference between providing 
 a new
 abstraction like a class and simply rewriting

 auto i = foo;

 as

 i := foo;

 _All_ it does is save you 4 characters and shift where in the 
 statement the
 piece is that tells the compiler to infer the type.

 - Jonathan M Davis


+1

I really hope such stuff will _never ever_ get into official D 
spec. It is just going to be a disaster for language that aims to 
be general-purpose and doesn't want to die because of minor 
detail overload complexity, like C++ did.

That syntax obession makes me afraid. Shorter lambdas had at 
least some rationale.
May 31 2013
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 05/31/2013 02:58 PM, Dicebot wrote:

 I really hope such stuff will _never ever_ get into official D spec. It is just
 going to be a disaster for language that aims to be general-purpose and doesn't
 want to die because of minor detail overload complexity, like C++ did.
 
 That syntax obession makes me afraid. Shorter lambdas had at least some
rationale.


I'm largely in agreement with you here, particularly because it seems
superfluous to add a feature that is _purely_ cosmetic when there are other,
very important language and library issues to resolve.

That said, could there be a case for a math { } environment, provided as a
library solution, that would enable a more maths-like syntax for those who
want/need it?
May 31 2013
prev sibling parent reply "Rob T" <alanb ucora.com> writes:
The := syntax looks just like the += *= ~= syntax, which has 
completely different meanings, so for some people it will only 
serve to confuse them more than they already are.

BTW D does have instances of multiple ways of doing the same 
things.

Eg

private:
    int x = 1;

private int x = 1;

private
{
   int x = 1;
}

--rt
May 31 2013
parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 31 May 2013 at 16:38:48 UTC, Rob T wrote:

 The := syntax looks just like the += *= ~= syntax, which has 
 completely different meanings, so for some people it will only 
 serve to confuse them more than they already are.

 BTW D does have instances of multiple ways of doing the same 
 things.

 Eg

 private:
    int x = 1;

 private int x = 1;

 private
 {
   int x = 1;
 }

 --rt


Yes, but these are *variations* of a common semantic.

You could also cite:
const i = 5;
const auto i = 5;

":=", on the other hand, is not a variation. It is something new 
and out of the blue.
May 31 2013
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 05/30/2013 10:39 PM, MrzlganeE wrote:

 In the case where it's a really basic thing that opens up a nice level of
 expressiveness for a different type of programmer, and there's no compromise
 that can bring us both together, it's OK to support us both!
 
 Because how can the current 'auto' work for both of us?
 How could I ever be happy writing math like that?


There is a compromise here, which is to define the Math template that Diggory
already suggested to you, and share it with the community.

Yes, you'll have to surround your code with mixin Math!q { ... }; statements,
which I know you'd prefer not to.  But on the other hand this has the advantage
of explicitly marking parts of the code which are intended to follow
mathematical notation.

And, having _done_ that, and made it available for others, it's possible to see
how many people find that option useful and whether or not there are any nasty
errors that could arise out of it (at least one person has already suggested a
potential typo-related bug).

If people _do_ find it useful, then you have a much better case for asking for
this syntactic sugar to be added to the language.
May 30 2013
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 30 May 2013 at 00:20:00 UTC, MrzlganeE wrote:

 Hi,

 Please consider a request for just one piece of syntax sugar in 
 D.

 In places where I write a bunch of short mathy code, I do not 
 want to use 'auto'. The := operator would allow to declare a 
 variable, deduce its type, and define its value.

 void main() {
     x := 1;
     y := 2.0;
     z := x * y;
     y = 3.0;
 }

 I do not want to see the word 'auto', because it has little to 
 do with the problem I am expressing. I find it distracting. 
 'auto' suggests D's type system -- but I am just thinking of 
 the algorithm. I want to see less words about the type system, 
 and focus my eyes on the problem that I am solving.

 I realize that D is not about syntax sugar, but this is 
 different:

 - It is easily understood by computer scientists, and 
 mathematicians coming from many different backgrounds -- it's 
 not obscure like a perl syntax construct.

 - I would not write 'auto' while expressing an algorithm on a 
 whiteboard. But I may very well write :=

 - It has a historical record of use in old BNF-grammar 
 languages.

 - I think people would really *use* it, where they don't want 
 to use auto today.

 - It's not 'un-C-like' -- it is only not-like-C, because C 
 didn't support the feature. It is actually a natural fit!

     for (i := 0; i < 24; i++) {
     }

 - It is very easily remembered: If you've seen it once, you 
 know it.

 Today, I would rather write 'double y = 2.0;' than 'auto y = 
 2.0;'
 But := would change that.

 Please consider it.

 - MrzlganeE


I'm not completely sold. The convenience seems good, but having 
declarations and assignments clearly separable is actually rather 
nice.

This sort of work would - along with other ideas such as physical 
units etc. - be best placed in a lightweight DSL (domain specific 
language) that simply hides the necessary mixins etc.

D lends itself to this wonderfully, it would make for a very nice 
mathematical/scientific language. I'm almost tempted to make such 
a language myself. Integrated with SciD.... ?? Hmmm, I feel a 
project coming on.
May 30 2013
parent "ixid" <nuaccount gmail.com> writes:
 This sort of work would - along with other ideas such as 
 physical units etc. - be best placed in a lightweight DSL 
 (domain specific language) that simply hides the necessary 
 mixins etc.

 D lends itself to this wonderfully, it would make for a very 
 nice mathematical/scientific language. I'm almost tempted to 
 make such a language myself. Integrated with SciD.... ?? Hmmm, 
 I feel a project coming on.


This could be a very interesting project. What do you think of 
Go's rules for inserting semi-colons? This and a few other tweaks 
(perhaps some of the parens removal too?) could allow a very 
elegant and minimal form of D, a subset with slightly stricter 
layout rules rather than a new language.
May 30 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
MrzlganeE:


 Please consider a request for just one piece of syntax sugar in 
 D.

 In places where I write a bunch of short mathy code, I do not 
 want to use 'auto'. The := operator would allow to declare a 
 variable, deduce its type, and define its value.

 void main() {
     x := 1;
     y := 2.0;
     z := x * y;
     y = 3.0;
 }

 I do not want to see the word 'auto', because it has little to 
 do with the problem I am expressing. I find it distracting. 
 'auto' suggests D's type system -- but I am just thinking of 
 the algorithm. I want to see less words about the type system, 
 and focus my eyes on the problem that I am solving.

 I realize that D is not about syntax sugar, but this is 
 different:

 - It is easily understood by computer scientists, and 
 mathematicians coming from many different backgrounds -- it's 
 not obscure like a perl syntax construct.

 - I would not write 'auto' while expressing an algorithm on a 
 whiteboard. But I may very well write :=

 - It has a historical record of use in old BNF-grammar 
 languages.

 - I think people would really *use* it, where they don't want 
 to use auto today.

 - It's not 'un-C-like' -- it is only not-like-C, because C 
 didn't support the feature. It is actually a natural fit!

     for (i := 0; i < 24; i++) {
     }

 - It is very easily remembered: If you've seen it once, you 
 know it.

 Today, I would rather write 'double y = 2.0;' than 'auto y = 
 2.0;'
 But := would change that.


I like the ":=" syntax because an assignment is an operation very 
different from an equality ("="). But then I'd like equality to 
be expressed with a single equal sign "=", both as in Pascal.

Generally in a language it's bad to have two ore more obvious 
ways to do something. D is almost compatible with C, so it has 
several duplications in the ways to do things. Such duplication 
is justified only when it introduces some significant advantage. 
This idea introduces a syntax duplication for not enough gain. So 
I am against it.

Bye,
bearophile
May 30 2013
prev sibling next sibling parent reply "someone" <someone gmail.com> writes:
Please think about the huge math and science community. Most of 
them I came across like D for its speed and efficiency. But D can 
never replace Matlab/Octave/Ipython/Scipy because ....

.. of the messy syntax compared to almost math like syntax above 
languages offer.

For example, if I want to quickly want to plot something, in 
Octave I would do:

x = linspace(0, 2*pi, 1000);
y = sin(x);
plot(x, y)


now, how to do that in D (assuming proper libs are already 
imported):

auto x = linspace(0, 2*pi, 1000);
auto y = sin(x);
plot(x, y)


the "auto" keyword seems to be a distraction. Compare it with the 
following code:

x := linspace(0, 2*pi, 1000);
y := sin(x);
plot(x, y)

For a code of several lines or 100s of lines auto becomes too 
much of a distraction. Especially when I want to quickly write a 
code to analyze some data I want the code to look like math as 
much as possible and not get distracted by too many language 
constructs.

You can say that D was never designed for that purpose, well, too 
bad then. D has so much potential to replace python/octave/matlab 
for math/scientific computing. Please give this a thought before 
dismissing the idea.
May 30 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 30 May 2013 at 14:55:38 UTC, someone wrote:

 Please think about the huge math and science community. Most of 
 them I came across like D for its speed and efficiency. But D 
 can never replace Matlab/Octave/Ipython/Scipy because ....

 .. of the messy syntax compared to almost math like syntax 
 above languages offer.

 For example, if I want to quickly want to plot something, in 
 Octave I would do:

 x = linspace(0, 2*pi, 1000);
 y = sin(x);
 plot(x, y)


I could be mistaken, but those languages don't have the notion of 
declaration, do they? (honest question)

Last time I tried a similar language, basically, any variable 
name that is not yet used is resolved to null. Which is why the 
syntax work.

D on the other hand has a strong notion of declaration, and 
construction.

I'm not sure it's just a matter of "messy syntax", and more of 
different paradigms. In D, it is more important to make the 
distinction of construction/assignment. The syntax is messy, but 
the new syntax blurs that line.
May 30 2013
next sibling parent reply "Diggory" <diggsey googlemail.com> writes:
On Thursday, 30 May 2013 at 15:05:40 UTC, monarch_dodra wrote:

 On Thursday, 30 May 2013 at 14:55:38 UTC, someone wrote:

 Please think about the huge math and science community. Most 
 of them I came across like D for its speed and efficiency. But 
 D can never replace Matlab/Octave/Ipython/Scipy because ....

 .. of the messy syntax compared to almost math like syntax 
 above languages offer.

 For example, if I want to quickly want to plot something, in 
 Octave I would do:

 x = linspace(0, 2*pi, 1000);
 y = sin(x);
 plot(x, y)


 I could be mistaken, but those languages don't have the notion 
 of declaration, do they? (honest question)

 Last time I tried a similar language, basically, any variable 
 name that is not yet used is resolved to null. Which is why the 
 syntax work.

 D on the other hand has a strong notion of declaration, and 
 construction.

 I'm not sure it's just a matter of "messy syntax", and more of 
 different paradigms. In D, it is more important to make the 
 distinction of construction/assignment. The syntax is messy, 
 but the new syntax blurs that line.


There's another alternative that fits more with D style which is 
also very mathsy.

It would be possible to make storage classes work with the colon 
syntax, ie:

auto:
    x = 1;
    y = 2;
    f = a => a+1
    writeln(f(x) + y);

Also:

immutable:
    x = 3;
    y = 4;

Kind of like option explicit: off in VB
May 30 2013
next sibling parent reply Timothee Cour <thelastmammoth gmail.com> writes:
In this:
auto:
   x = 1;
   y = 2;
   f = a => a+1
   writeln(f(x) + y);

where do you delimit the end of the 'auto:' scope?
Actually this is already possible like that:
auto
  x=1,
  y=2;


On Thu, May 30, 2013 at 9:18 AM, Diggory <diggsey googlemail.com> wrote:


 On Thursday, 30 May 2013 at 15:05:40 UTC, monarch_dodra wrote:


 On Thursday, 30 May 2013 at 14:55:38 UTC, someone wrote:


 Please think about the huge math and science community. Most of them I
 came across like D for its speed and efficiency. But D can never replace
 Matlab/Octave/Ipython/Scipy because ....

 .. of the messy syntax compared to almost math like syntax above
 languages offer.

 For example, if I want to quickly want to plot something, in Octave I
 would do:

 x = linspace(0, 2*pi, 1000);
 y = sin(x);
 plot(x, y)


 I could be mistaken, but those languages don't have the notion of
 declaration, do they? (honest question)

 Last time I tried a similar language, basically, any variable name that
 is not yet used is resolved to null. Which is why the syntax work.

 D on the other hand has a strong notion of declaration, and construction.

 I'm not sure it's just a matter of "messy syntax", and more of different
 paradigms. In D, it is more important to make the distinction of
 construction/assignment. The syntax is messy, but the new syntax blurs that
 line.


 There's another alternative that fits more with D style which is also very
 mathsy.

 It would be possible to make storage classes work with the colon syntax,
 ie:

 auto:
    x = 1;
    y = 2;
    f = a => a+1
    writeln(f(x) + y);

 Also:

 immutable:
    x = 3;
    y = 4;

 Kind of like option explicit: off in VB
May 30 2013
parent "Diggory" <diggsey googlemail.com> writes:
On Thursday, 30 May 2013 at 16:59:42 UTC, Timothee Cour wrote:

 In this:
 auto:
    x = 1;
    y = 2;
    f = a => a+1
    writeln(f(x) + y);

 where do you delimit the end of the 'auto:' scope?


At the end of the current scope - same rules as normal.

You can use { ... } to create a new scope where necessary.
May 30 2013
prev sibling parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
"Diggory" <diggsey googlemail.com> writes:

 There's another alternative that fits more with D style which is also
 very mathsy.

 It would be possible to make storage classes work with the colon
 syntax, ie:

 auto:
    x = 1;
    y = 2;
    f = a => a+1
    writeln(f(x) + y);

 Also:

 immutable:
    x = 3;
    y = 4;

 Kind of like option explicit: off in VB


Hmmm, why hasn't anybody just suggested doing this?  It seems to work
fine in dmd.

    auto
        x = 23.5,
        y = 14,
        z = y*x,
        s = "foo",
        w = z * s.length;

OR

    immutable
        x = 23.5,
        y = 14,
        z = y*x,
        s = "foo",
        w = z * s.length;
May 30 2013
parent Timothee Cour <thelastmammoth gmail.com> writes:
I did... Earlier in that thread :)
On May 30, 2013 7:50 PM, "Dan Olson" <zans.is.for.cans yahoo.com> wrote:


 "Diggory" <diggsey googlemail.com> writes:

 There's another alternative that fits more with D style which is also
 very mathsy.

 It would be possible to make storage classes work with the colon
 syntax, ie:

 auto:
    x = 1;
    y = 2;
    f = a => a+1
    writeln(f(x) + y);

 Also:

 immutable:
    x = 3;
    y = 4;

 Kind of like option explicit: off in VB


 Hmmm, why hasn't anybody just suggested doing this?  It seems to work
 fine in dmd.

     auto
         x = 23.5,
         y = 14,
         z = y*x,
         s = "foo",
         w = z * s.length;

 OR

     immutable
         x = 23.5,
         y = 14,
         z = y*x,
         s = "foo",
         w = z * s.length;
May 30 2013
prev sibling next sibling parent "Geancarlo Rocha" <asdf mailinator.com> writes:
On Thursday, 30 May 2013 at 15:05:40 UTC, monarch_dodra wrote:

 I could be mistaken, but those languages don't have the notion 
 of declaration, do they? (honest question)

 Last time I tried a similar language, basically, any variable 
 name that is not yet used is resolved to null. Which is why the 
 syntax work.


FYI:

MATLAB:


 x = linspace(0, 2*pi, 1000);




y = sin(x);
plot(x, y)

 disp(z)




??? Undefined function or variable 'z'.


Python(IDLE):


 print x






Traceback (most recent call last):

     print x
NameError: name 'x' is not defined
May 30 2013
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 30 May 2013 at 15:05:40 UTC, monarch_dodra wrote:

 On Thursday, 30 May 2013 at 14:55:38 UTC, someone wrote:

 Please think about the huge math and science community. Most 
 of them I came across like D for its speed and efficiency. But 
 D can never replace Matlab/Octave/Ipython/Scipy because ....

 .. of the messy syntax compared to almost math like syntax 
 above languages offer.

 For example, if I want to quickly want to plot something, in 
 Octave I would do:

 x = linspace(0, 2*pi, 1000);
 y = sin(x);
 plot(x, y)


 Last time I tried a similar language, basically, any variable 
 name that is not yet used is resolved to null. Which is why the 
 syntax work.


Not quite.

The paradigm in python/matlab etc. could be expressed as 
"initialisation is declaration". It works ok.

IDL (interactive data language, not interface description 
language) takes it to the next level by allowing undeclared 
variables to be passed as output parameters to a function. Which, 
combined with single return types and a strict separation of 
procedures and functions, each with different calling syntax, is 
horrible.
May 30 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/29/2013 5:19 PM, MrzlganeE wrote:

 In places where I write a bunch of short mathy code, I do not want to use
 'auto'. The := operator would allow to declare a variable, deduce its type, and
 define its value.


Not a bad idea. But why not go a step further, and make:

    x := value;

the equivalent of:

    const x := value;

?
May 30 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 Not a bad idea. But why not go a step further, and make:

    x := value;

 the equivalent of:

    const x := value;

 ?


Of course. But I think that syntax saves only a small amount of 
chars, and it adds a second obvious way to do one thing.

There is another syntax that's missing in D that I think is much 
more useful, and it allows to do something that currently has no 
good way to be done.

Bye,
bearophile
May 30 2013
prev sibling parent reply "MrzlganeE" <bulletproofchest gmail.com> writes:
 Not a bad idea. But why not go a step further, and make:

    x := value;

 the equivalent of:

    const x := value;

 ?



This one is really hard for me to offer input on:

I could get a lot done with the const version.

I could agree with you for multiple reasons I think,
- const x := 1; still works, yet it's redundant with the = 
operator.
- writing const style code is good in math
- the := fits into FP-style code too
- := has some historical precedence (in the parsers) (but not in 
the languages) for meaning const

And I'd be happy with compromise.

But personally, I did truly want to use it for the non const 
stuff, too, even if I don't want to admit that. I'd use it for a 
lot of stuff.

Which leads me to dare suggest there could be 2 operators ....
:= and $=, the latter for const (Guys you may be mad now, people 
would like the $= later on...)

But please, don't let that worry you!

I only ask for the simplest change, if there could be any 
compromise.
May 30 2013
next sibling parent reply "MrzlganeE" <bulletproofchest gmail.com> writes:
:= and $= and just run with it.
May 30 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/30/2013 03:15 PM, MrzlganeE wrote:


 := and $= and just run with it.


Let's not forget immutable and shared either. How about their initials 
for mutable, const, immutable, and shared? I am more than half joking. :)

a m= 42;
b c= 43;
c i= 44;
d s= 45;

Ali
May 30 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/30/13 7:20 PM, Ali Çehreli wrote:

 On 05/30/2013 03:15 PM, MrzlganeE wrote:

  > := and $= and just run with it.

 Let's not forget immutable and shared either. How about their initials
 for mutable, const, immutable, and shared? I am more than half joking. :)

 a m= 42;
 b c= 43;
 c i= 44;
 d s= 45;

 Ali


I'd say we must somehow get to the Johnny Bravo emoticon.

(:=


Andrei
May 30 2013
next sibling parent reply "MrzlganeE" <bulletproofchest gmail.com> writes:
There's still one left,

 =
May 30 2013
parent "MrzlganeE" <bulletproofchest gmail.com> writes:
If  = is any more friendly, I could propose it also for const.
May 30 2013
prev sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 31 May 2013 at 00:25:16 UTC, Andrei Alexandrescu wrote:

 I'd say we must somehow get to the Johnny Bravo emoticon.

 (:=


 Andrei


m :=
c (:=
i [:=
s |:=
May 30 2013
prev sibling next sibling parent reply "Math guy" <google yahoo.com> writes:
 But personally, I did truly want to use it for the non const 
 stuff, too, even if I don't want to admit that. I'd use it for 
 a lot of stuff.


Yes, I desire the same thing. The day I get this, I will abandon 
python/octave for  D for doing mathsy data analysis.
May 30 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/30/13 6:26 PM, Math guy wrote:

 But personally, I did truly want to use it for the non const stuff,
 too, even if I don't want to admit that. I'd use it for a lot of stuff.


 Yes, I desire the same thing. The day I get this, I will abandon
 python/octave for D for doing mathsy data analysis.


I don't think it works that way.

Andrei
May 30 2013
parent "Math guy" <google yahoo.com> writes:
 I don't think it works that way.


Yaa, I did exaggerate it a little, and didn't say it properly.

What I meant is that if that assignment operator is implemented, 
I would port my engineering/math libraries I use at my work to D, 
and try to convince my colleagues to use D with my libraries. All 
my colleagues are addicted to matlab and also complain at the 
same time that the matlab is slow. Every one here hates typing 
the data types (and typed languages in general), and want the 
code to look like math as much as possible.

The other language they reluctantly agreed to use is python, but 
I was hoping it would be D.
May 31 2013
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 30 May 2013 18:14:18 -0400, MrzlganeE <bulletproofchest gmail.com>  
wrote:


 Not a bad idea. But why not go a step further, and make:

    x := value;

 the equivalent of:

    const x := value;

 ?



 This one is really hard for me to offer input on:

 I could get a lot done with the const version.

 I could agree with you for multiple reasons I think,
 - const x := 1; still works, yet it's redundant with the = operator.


I think Walter meant:

const x = value;

-Steve
May 30 2013
parent "MrzlganeE" <bulletproofchest gmail.com> writes:
Regarding the $, I am worried for suggesting it cause I don't 
want to mess up any proposal

It would be easier to suggest, if the $ didn't look so odd.
The "$" is a funny looking symbol.

I was imagining how the shape of the C, and the S, and almost a T 
is within the $, and it's crossed out to show you should not 
alter it. Yet those thoughts are very abstract.

So, I would be happy with any of the 3.
- := is nonconst
- := is const
- := and $=
May 30 2013
prev sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 30/05/13 18:43, Russel Winder wrote:

 On Thu, 2013-05-30 at 02:19 +0200, MrzlganeE wrote:
 […]

 In places where I write a bunch of short mathy code, I do not
 want to use 'auto'. The := operator would allow to declare a
 variable, deduce its type, and define its value.

 void main() {
       x := 1;
       y := 2.0;
       z := x * y;
       y = 3.0;
 }


 […]

       for (i := 0; i < 24; i++) {
       }


 Go does exactly this, and it is good.

 Less is more.


Except in the case of Go with their inane policy of injecting ';' into 
the lexical analyser at the end of lines for the sake of brevity.

Peter
May 30 2013