const functions in D 2.0

[Adam Burton]

Nathan Reed wrote:

> Steven Schveighoffer wrote:
>> "Jarrett Billingsley" wrote
>>> "Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message
>>> news:fgoak7$24ao$1 at digitalmars.com...
>>>> How does one declare const/invariant member functions in D 2.0 that
>>>> don't
>>>> return void?  If it's just prefixing, how does one declare
>>>> const/invariant functions that return const/invariant references?
>>>>
>>>> The web site isn't very helpful on this matter.
>>>>
>>>> -Steve
>>>>
>>> const Bar foo()
>>> {
>>>    // returns a non-const Bar, but can't modify this.
>>> }
>>>
>>> const const(Bar) foo()
>>> {
>>>    // returns a const(Bar).
>>> }
>>>
>>> At least I'm pretty sure.
>>>
>> 
>> Experimentation proves you are correct.  Thanks!
>> 
>> This really should be more prominent on the web site.
> 
> Actually, this really should be changed in the language...it's kind of
> silly IMHO that const Bar foo() and const(Bar) foo() mean different
> things.
> 
> How about putting the const or invariant of a function at the end of the
> function header like C++ does?
> 
>      Bar foo () const    // ret-val is not const, 'this' is
> 
> I don't know what was so wrong with this aspect of C++ syntax that it
> had be replaced with the confusing syntax we have now.
> 
> Thanks,
> Nathan Reed
Hi,
I have not really followed the changes made in D 2.0, only really know the
const-correctness piece, so bare with me on my suggestion :-). You might
think I have over analysed the situation, as I personally see this as a
trivial problem myself, however I think I have a point that should at least
be considered if a decision to modify the language is made as the language
needs stay well structured (as I don't believe 'cos it looks nicer in c++'
is good enough justification to make a language change (sorry sounds a kind
of harsh way of putting it but its not intended to be)).

I would assume the reason 'const' was put at the front of the method
prototype is because 'const' is the method modifier(/whatever you wanna
call it) in the same way 'override' and 'abstract' modify the methods
meaning, therefore it belongs in the same place as
abstract/override/final/etc. Unfortunately the modifiers for types are
placed at the front as well, as there seems to be a subtle rule that
modifiers precede what they are modifying, causing ambiguity in this
particular circumstance.

By appending 'const' but not abstract/override/final/etc you might be
implying it is a special purpose modifier in comparison to the others.

The way I see it there's 3 possible solutions.

1.
As proposed by Nathan just put 'const' at the end of the method prototype
like C++.
<<method modifiers>> <<type modifiers>> <<return type>> <<methodname>>()
<<clashing modifiers>>

examples:
Bar foo() const
const Bar foo() const
override const Bar foo() const

Advantages:
moving from D1.0 to D2.0 you don't require any code changes unless
implementing const-correctness.
C++ people will pick it up quite easily.
Disadvantages:
Implies 'const' has a separate purpose from abstract/override/final/etc
adding another syntax rule to method prototypes. (on the other hand maybe
it does have a different purpose since I assume 'const' can be used on
stand alone functions where as final/abstract/override/etc require a class
method).
'override const Bar foo() const' -> since we know the second 'const' is for
the method only we know the first is for 'Bar', however if your quickly
skipping through code, or are new, it may cause some confusion
that 'override' and the first 'const' are modifying different things (like
I mentioned earlier, adding another syntax rule).

2.
<<type modifier>> <<return type>> <<method modifier>> <<methodname>>()
examples:
Bar const foo()
const Bar const foo()
const Bar override const foo()

Advantages:
Clear separation between method modifiers and type modifiers, even if your
skipping through the code fairly quickly.
Still follows what seems to be a general rule that the modifiers precede
whatever they are modifying.
Disadvantages:
Requires code change from D1.0 to D2.0 even if your not implementing
const-correctness (however I am sure someone could implement a conversion
tool that can handle this trivial change).
Looks kinda evil since it changes what people are accustomed too looking at.
It gets worse when you have lots of modifiers, like 'const Bar public const
override deprecated foo()'. Isn't the purpose of syntax highlighters to
make it easier to read code allowing the language to follow a common
structure that at times might seem ugly.

3.
<<type modifier>> <<return type>> <<method name>>() <<method modifiers>>
examples:
Bar foo() const 
const Bar foo() const 
const Bar foo() override const 

Advantages:
Clear separation between method modifiers and type modifiers, even if your
skipping through the code fairly quickly.
To me seems easier to read than previous example (unless you have a syntax
highlighter then its just as easy), even though it still makes some changes
that people would not be accustomed too.
Disadvantages:
Requires code change from D1.0 to D2.0 even if your not implementing
const-correctness (however I am sure someone could implement a conversion
tool that can handle this relatively trivial change).
Breaks whats seems to be the subtle rule that modifiers precede what it's
changing.

I am personally comfortable with all the options, however I think option 2
is probably the way it should be going as it keeps syntax rules to a
minimum, even if it is ugly. Thanks to the miracle of syntax highlighters I
think option 2 will not look so ugly, allowing the language to follow a
more structured pattern.

Personally I think I have a good point, I also welcome suggestions that may
pick my idea to pieces with good reasoning.
If I was to submit this on to the person who writes the specification for D
(I believe he is called Walter?) how would I go about doing so?

Regards,
Adam