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

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.

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

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

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.

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

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;

?

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

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;

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)