a more consistent const syntax

[Chris Nicholson-Sauls]

Daniel919 wrote:
> Chris Nicholson-Sauls schrieb:
>> Daniel919 wrote:
>>>
>>> confusions and solutions:
>>> -------------------------
>>> #1
>>> 1. const x = 1;
>>> 2. const(P) p = new Point(1,2);
>>> you see const first and later recognize the brackets
>>> one would not expect brackets to lead to a completely different 
>>> meaning of the forrun keyword
>>
>> My eyes are trained to spot them... still yes, a sudden shift in 
>> meaning can be counter-intuitive.  Although its not entirely a 
>> shift...  you could probably think of 'const x = 1;' as shorthand for 
>> 'final const(int) x = 1;'.
> 
> But they are not the same:
> 
> const x = 1;
> doesn't take up space
> 
> final const(int) x = 1;
> does take up space
> 

Just like 'invariant' does.  Gotcha.  Maybe the rule should be as I 
"suggested" with the implication that 'final' values of a basic type and 
an in-place initializer do not take up space?  Or at least in the 
context of final+const|invariant.

Then again, the current behavior at least works.

>> Adding new keywords is usually the absolute last option around here. 
>> (There was talk ages past of replacing 'auto x = 1' with 'let x = 1'.)
> 
> You might think about spoken languages: You learn more vocabularies to 
> be able to differentiate better, so you are more capable to express what 
> you mean, instead of relying on an absolutely small subset of vocabularies.
> PS: "auto" also was a new keyword some time ago ;)
> 
> "define" is also known from C/C++ world to define something you can't 
> change, equivalent to what const x = 1; acutally means: not an lvalue.
> In my opinion it's better to have a different keyword for something 
> different, and "define" makes much sense for me.

Granted; I'm just saying it'll be more work to sell a new keyword.  Your 
nomination of 'define' is itself sound.  (I'm sure we'll never get the 
Ruby rule of "just start the name with a capital letter".  ;))

>>> further proposal: returned types in a bracket at the end:
>>> 3. const func (P p) (P) { ... }
>>> //templated syntax: const func!(T) (T p) (T) { ... }
>>
>> Uhm.  Ew.  [etc]
> 
> You are right, it really looks like a template instatiation.
> So lets try without the ! on declaration:
> 
> func(T) (T var) (T)  //IFTI  take T  return T
> func(T) (T var)      //IFTI  take T
> func(T) () (T)       //IFTI          return T
> func(T)              //IFTI
> func(T var) (T)      //      take T  return T
> func(T var)          //      take T
> func() (T)           //              return T
> func()               //
> 
> At least one () should remain, to make clear that it's a function
> 
> Before the return brackets there must always be the take brackets.
> So 4. can only mean IFTI.
> 
> This looks good in my opinion.

Its... different.  And I suppose workable, particularly if it were made 
optional -- that is, let the current syntax stand, and allow this as an 
alternate syntax.  I do like the idea of:
func() { ... }

Being apparently equivelant to:
void func() { ... }

I think perhaps I'm just too "fond" (ie, comfortable, familiar) with the 
'M... R func(A)' syntax and therefore scared to change it.  Especially 
since it'd be a radical change at this point in the game.  (At least for 
D/1.0)

>> 'const'/'invariant' keyword on methods that needs to move -- not sure 
>> where it should go, though.  What looks best down here?  ;)  (First 
>> listing is the current state, for reference.)
>>
>> const P       vunc       (P p)       { ... }
>>       P const func       (P p)       { ... }
>>       P const:func       (P p)       { ... }
>>       P const(func)      (P p)       { ... }
>>       P       func const (P p)       { ... }
>>       P       func:const (P p)       { ... }
>>       P       func       (P p) const { ... }
>>
> 
> I would suggest
> const: P func (P p) { ... }
> 
> Not allowed:
> const:
>  ... func1 ...
>  ... func2 ...
> 
> You always have to explicitly mention the "const:" for each function.
> 
> This way the "attribute feeling" is retained.

Actually... I like it.

>> [snip]  At least you're thinking about the situation 
>> and offering suggestions.  (And welcome to the tiny militia of 'const 
>> R func()' syntax detractors. ;))  The final/const/invariant system 
>> needs some good hammering yet -- although its off to a lovely start, 
>> danke Walter.
>>
> 
> Yes, there seem to be a lot of people not being very happy with the 
> current const syntax.
> But I have not seen much concrete suggestion how to make it better.
> 

Its a tough nut to crack.  Chances are we really need to just do 
something crazy and new... its the coming-up-with-something-new part 
that's hard.

A 'func(T...)(A...)(R)' function syntax, though.  Now that's new. :)

-- Chris Nicholson-Sauls