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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--047d7b33d0042c9e4204dde6bb07
Content-Type: text/plain; charset=ISO-8859-1

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{ ... };

--047d7b33d0042c9e4204dde6bb07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable mixins make the code more ugly and the error messages&#39; line numbers wil= l not be in sync with the code, IIRC.<div>I would like this syntax sugar to= o.</div><div><br></div><div>It&#39;s also used in GO, btw.<br><br><div clas= s=3D"gmail_quote"> On Wed, May 29, 2013 at 7:52 PM, Diggory <span dir=3D"ltr">&lt;<a href=3D"m= ailto:diggsey googlemail.com" target=3D"_blank">diggsey googlemail.com</a>&= gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Thursday, 30 May 2013 at 02:51:4= 7 UTC, Diggory wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Thursday, 30 May 2013 at 01:35:58 UTC, MrzlganeE wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Diggory: =A0That&#39;s very cool -- being able to do that in D. Thanks for = showing me :)<br> <br> But it is not even a remotely practical solution.<br> =A0 =A0The idea is to write less, and so the solution you&#39;ve given is t= o write more mixins all over the place. I said I don&#39;t even want to wri= te &#39;auto&#39;, I am surely not writing the big mixin chunk.<br> <br> I only gave an example of math stuff.<br> But I&#39;d use :=3D for the non-math stuff too.<br> <br> I want :=3D it to be available everywhere.<br> Even if I am just typing a snippet into dpaste.<br> <br> If D implements this, C++ will try to copy it 10 years later.<br> It&#39;s a futuristic thing -- what is old is new.<br> </blockquote> <br> The mixin definition only needs to exist once, and you can use &quot;mixin&= quot; anywhere - you could wrap an entire source file in it:<br> <br> mixin!q{<br> <br> /* All of your code */<br> <br> }<br> </blockquote> <br></div></div> *mixin Math!q{ ... };<br> </blockquote></div><br></div> --047d7b33d0042c9e4204dde6bb07--
May 29 2013
prev sibling next 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 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
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:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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;
 }

=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
 }

[=E2=80=A6] =20
      for (i :=3D 0; i < 24; i++) {
      }

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 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
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 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
prev sibling next 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 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
 #(int, int) positionTuple() { return #(1, 2); } //assuming #() for tuples

 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 next 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 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 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 "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
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 next sibling parent "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
prev sibling 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 "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 "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
prev sibling 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 "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
prev sibling next sibling parent 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
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 :=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
prev sibling 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 "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
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 "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
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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--089e013cbd90fd415504ddf26b90
Content-Type: text/plain; charset=ISO-8859-1

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

--089e013cbd90fd415504ddf26b90 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>In this:</div>auto:<br>=A0 =A0x =3D 1;<br>=A0 =A0y =3D 2;<br>=A0 =A0f = =3D a =3D&gt; a+1<br>=A0 =A0writeln(f(x) + y);<br><br>where do you delimit = the end of the &#39;auto:&#39; scope?<div>Actually this is already possible= like that:</div><div> <font face=3D"Menlo"><span style=3D"color:#009695">auto</span><span style= =3D"color:#444444">=A0</span><br><span style=3D"color:#444444">=A0=A0</span=
<span style=3D"color:#444444">x</span><span style=3D"color:#444444">=3D</s=

span><br> <span style=3D"color:#444444">=A0=A0</span><span style=3D"color:#444444">y<= /span><span style=3D"color:#444444">=3D</span><span style=3D"color:#f57d00"=
2</span><span style=3D"color:#444444">;</span><br>

te">On Thu, May 30, 2013 at 9:18 AM, Diggory <span dir=3D"ltr">&lt;<a href= =3D"mailto:diggsey googlemail.com" target=3D"_blank">diggsey googlemail.com= </a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On T= hursday, 30 May 2013 at 15:05:40 UTC, monarch_dodra wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Thursday, 30 May 2013 at 14:55:38 UTC, someone wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> 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 ....<br> <br> .. of the messy syntax compared to almost math like syntax above languages = offer.<br> <br> For example, if I want to quickly want to plot something, in Octave I would= do:<br> <br> x =3D linspace(0, 2*pi, 1000);<br> y =3D sin(x);<br> plot(x, y)<br> </blockquote> <br> I could be mistaken, but those languages don&#39;t have the notion of decla= ration, do they? (honest question)<br> <br> 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.<br> <br> D on the other hand has a strong notion of declaration, and construction.<b= r> <br> I&#39;m not sure it&#39;s just a matter of &quot;messy syntax&quot;, and mo= re of different paradigms. In D, it is more important to make the distincti= on of construction/assignment. The syntax is messy, but the new syntax blur= s that line.<br> </blockquote> <br></div></div> There&#39;s another alternative that fits more with D style which is also v= ery mathsy.<br> <br> It would be possible to make storage classes work with the colon syntax, ie= :<br> <br> auto:<br> =A0 =A0x =3D 1;<br> =A0 =A0y =3D 2;<br> =A0 =A0f =3D a =3D&gt; a+1<br> =A0 =A0writeln(f(x) + y);<br> <br> Also:<br> <br> immutable:<br> =A0 =A0x =3D 3;<br> =A0 =A0y =3D 4;<br> <br> Kind of like option explicit: off in VB<br> </blockquote></div><br></div> --089e013cbd90fd415504ddf26b90--
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.

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


plot(x, y)
 disp(z)


Python(IDLE):
 print x



Traceback (most recent call last): File "<pyshell#0>", line 1, in <module> print x NameError: name 'x' is not defined
May 30 2013
prev sibling next sibling 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 next sibling 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 "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)

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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "MrzlganeE" <bulletproofchest gmail.com> writes:
And the alternative:

x, y, z := f(), g(), h();
May 30 2013
prev sibling next sibling 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 "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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling parent "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
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 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 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
prev sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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
prev sibling next sibling parent "MrzlganeE" <bulletproofchest gmail.com> writes:
:= and $= and just run with it.
May 30 2013
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling 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

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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--089e013c709aaedf8504ddf897f3
Content-Type: text/plain; charset=UTF-8

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? --089e013c709aaedf8504ddf897f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 30 May 2013 23:13, MrzlganeE <span dir=3D"ltr">&lt;<a h= ref=3D"mailto:bulletproofchest gmail.com" target=3D"_blank">bulletproofches= t gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class= =3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">I hate you all, and with this, I exit the D = community<br> <br> The only reason I was here was I dreamed that I could get a couple of featu= res<br> </blockquote></div><br></div><div class=3D"gmail_extra" style>You need to s= how SOME investment/commitment to the language before anybody is going to t= ake your proposals seriously.</div><div class=3D"gmail_extra" style>Have yo= u ever written any D code? Shared it?</div> </div> --089e013c709aaedf8504ddf897f3--
May 30 2013
prev sibling next 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 Manu <turkeyman gmail.com> writes:
--089e0115ed1697be3004ddf8cdb8
Content-Type: text/plain; charset=UTF-8

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... --089e0115ed1697be3004ddf8cdb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 31 May 2013 00:59, Byron Heads <span dir=3D"ltr">&lt;<a= href=3D"mailto:byron.heads gmail.com" target=3D"_blank">byron.heads gmail.= com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail= _quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Thursday, 30 May 2013 at 14:41:09 UTC, Byron Heads wro= te:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On Thursday, 30 May 2013 at 14:27:13 UTC, Russel Winder wrote:<br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> I still like:<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 x :=3D 1<br> <br> for a declaration and initialization with type inference.<br> </blockquote> <br> <br> Could be used for assigning from tuples.<br> <br> iVal, sVal :=3D returnsIntAndString();<br> <br> would have to decide on how to handle this<br> x :=3D 1;<br> x :=3D y * 7; =C2=A0// error or assignment?<br> <br> more of an issue with tuples then single lvalues<br> </div></blockquote> <br> could also be used without the type inference<br> <br> int x;<br> x, string s :=3D returnIntAndString();<br> ------<br> int wx, wy;<br> ...<br> wx, wy :=3D window.position;<br> </blockquote></div><br></div><div class=3D"gmail_extra" style>I&#39;ve rais= ed the topic of multiple-return-values a whole heap of times. It&#39;s usua= lly shot down because it would create ambiguities in existing syntax.</div> <div class=3D"gmail_extra" style>MRV is super useful, and potentially more = efficient too (in an ABI where MRV can each return in arg registers, can sa= ve lots of memory hazards). It produces a situation where you can return mo= re than a single value from a leaf function (really handy!).</div> <div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
So, I&#39;m very curious to explore how any new assignment syntax can inte=

--089e0115ed1697be3004ddf8cdb8--
May 30 2013
prev sibling next sibling parent "MrzlganeE" <bulletproofchest gmail.com> writes:
There's still one left,

 =
May 30 2013
prev sibling next 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
prev sibling next sibling parent "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
prev sibling next sibling parent "MrzlganeE" <bulletproofchest gmail.com> writes:
If  = is any more friendly, I could propose it also for const.
May 30 2013
prev sibling next sibling parent "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
prev sibling next 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 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
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--20cf307abd9d35fe9104ddfba2fa
Content-Type: text/plain; charset=ISO-8859-1

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;

--20cf307abd9d35fe9104ddfba2fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p dir=3D"ltr">I did... Earlier in that thread :)</p> <div class=3D"gmail_quote">On May 30, 2013 7:50 PM, &quot;Dan Olson&quot; &= lt;<a href=3D"mailto:zans.is.for.cans yahoo.com">zans.is.for.cans yahoo.com= </a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> &quot;Diggory&quot; &lt;<a href=3D"mailto:diggsey googlemail.com">diggsey g= ooglemail.com</a>&gt; writes:<br> &gt;<br> &gt; There&#39;s another alternative that fits more with D style which is a= lso<br> &gt; very mathsy.<br> &gt;<br> &gt; It would be possible to make storage classes work with the colon<br> &gt; syntax, ie:<br> &gt;<br> &gt; auto:<br> &gt; =A0 =A0x =3D 1;<br> &gt; =A0 =A0y =3D 2;<br> &gt; =A0 =A0f =3D a =3D&gt; a+1<br> &gt; =A0 =A0writeln(f(x) + y);<br> &gt;<br> &gt; Also:<br> &gt;<br> &gt; immutable:<br> &gt; =A0 =A0x =3D 3;<br> &gt; =A0 =A0y =3D 4;<br> &gt;<br> &gt; Kind of like option explicit: off in VB<br> <br> Hmmm, why hasn&#39;t anybody just suggested doing this? =A0It seems to work= <br> fine in dmd.<br> <br> =A0 =A0 auto<br> =A0 =A0 =A0 =A0 x =3D 23.5,<br> =A0 =A0 =A0 =A0 y =3D 14,<br> =A0 =A0 =A0 =A0 z =3D y*x,<br> =A0 =A0 =A0 =A0 s =3D &quot;foo&quot;,<br> =A0 =A0 =A0 =A0 w =3D z * s.length;<br> <br> OR<br> <br> =A0 =A0 immutable<br> =A0 =A0 =A0 =A0 x =3D 23.5,<br> =A0 =A0 =A0 =A0 y =3D 14,<br> =A0 =A0 =A0 =A0 z =3D y*x,<br> =A0 =A0 =A0 =A0 s =3D &quot;foo&quot;,<br> =A0 =A0 =A0 =A0 w =3D z * s.length;<br> </blockquote></div> --20cf307abd9d35fe9104ddfba2fa--
May 30 2013
prev sibling next sibling parent "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 #(int, int) positionTuple() { return #(1, 2); } //assuming #() 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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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
prev sibling next sibling 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 next sibling 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 next 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 next sibling parent "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
prev sibling next sibling 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 next 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 next sibling parent "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
prev sibling 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