www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - const functions in D 2.0

reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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 
Nov 05 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:fgoak7$24ao$1 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.
Nov 05 2007
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Jarrett Billingsley" wrote
 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
 news:fgoak7$24ao$1 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. -Steve
Nov 05 2007
parent reply Nathan Reed <nathaniel.reed gmail.com> writes:
Steven Schveighoffer wrote:
 "Jarrett Billingsley" wrote
 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
 news:fgoak7$24ao$1 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

{ // 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
Nov 05 2007
parent Adam Burton <adz21c googlemail.com> writes:
Nathan Reed wrote:

 Steven Schveighoffer wrote:
 "Jarrett Billingsley" wrote
 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:fgoak7$24ao$1 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

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

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
Nov 06 2007