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

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

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

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

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.

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?

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

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.

> 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.

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