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?

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

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

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.

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

There's still one left,

@=

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

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

If @= is any more friendly, I could propose it also for const.

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