www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: const/immutable member functions

reply foobar <foo bar.com> writes:
Don Wrote:

 Steven Schveighoffer wrote:
 On Mon, 24 Jan 2011 13:36:36 -0500, bearophile 
 <bearophileHUGS lycos.com> wrote:
 
 There are six, seven or more people that wish to do something about 
 this situation. TDPL is the D2 reference, but few little changes over 
 its first edition are acceptable if they improve the D language a little.

 - Trass3r: asks if the code is ambiguous
 - Jonathan M Davis: does't like it and puts const/etc on the right
 - Simen kjaeraas thinks it's ambiguous though, and should be 
 disallowed, or at very least, discouraged.
 - Jens Mueller: Preferred style is to write const on the right
 - Andrej Mitrovic suggests to use   but says it clutters up source code.
 - I agree with Jonathan M Davis.

 What other people think about this situation? Do you want 
 const/immutable to be required on the right, or do you prefer the 
 current situation, or do you prefer some other solution?

I wouldn't say that I *prefer* the current solution, but the current solution is not so bad that I need it changed. It works fine, despite being confusing. If it wasn't consistent with the rest of the attributes, I'd say it was in need of changes, but it fits within the scheme already outlined.

It's a problem for all of the other attributes as well. I wish it were disallowed for all of them. Incidentally, putting it afterward always works. Putting it before doesn't always work, due to compiler bugs (for example, prefix 'pure' doesn't work for inner functions).

This "problem" happens because D belongs to the C-family of languages which puts the return type _before_ the function name. Languages that don't follow this syntactic convention (some would call it a mistake) have it very consistent and readable: attribute funcName inputParams -> outputParams { body } This is the typical functional language design. Of course I'm not suggesting to apply such a huge change to D but if I were to design a brand new language than I would put the return type at the end. I feel that putting function attributes at the end increases this IMHO bad design which boils down to a right-to-left programming language. I'm a native Hebrew speaker and it looks weird to me, so I can't imagine how it could look right to any left-to-right language native speaker...
Jan 24 2011
next sibling parent reply so <so so.do> writes:
 This "problem" happens because D belongs to the C-family of languages  
 which puts the return type _before_ the function name.

It has nothing to do with being a C-family language. C/C++ don't have this, and the rules are perfectly clear. It is just unifying two or more unrelated things in one syntax for the sake of consistency (and compiler complexity?).
Jan 24 2011
next sibling parent reply foobar <foo bar.com> writes:
so Wrote:

 This "problem" happens because D belongs to the C-family of languages  
 which puts the return type _before_ the function name.

It has nothing to do with being a C-family language. C/C++ don't have this, and the rules are perfectly clear. It is just unifying two or more unrelated things in one syntax for the sake of consistency (and compiler complexity?).

C++ style aka Yoda style: 1. public double func(int input) const; 2. const double func(int input); 3. const double func(int input) const; VS. hypothetical left-to-right style: 1. public const func (int input) -> (double); 2. func (int input) -> (const double); 3. const func (int input) -> (const double); Which ordering makes for a more natural read?
Jan 24 2011
parent reply foobar <foo bar.com> writes:
so Wrote:

 C++ style aka Yoda style:
 1. public double func(int input) const;
 2. const double func(int input);
 3. const double func(int input) const;

 VS.
 hypothetical left-to-right style:
 1. public const func (int input) -> (double);
 2.  func (int input) -> (const double);
 3. const func (int input) -> (const double);

 Which ordering makes for a more natural read?

For you or for me? :)

Look at this from a "It reads like English" prospective and not from a "I'm an experienced c++ programmer and therefore already used to this crap" perspective. In other words, if you were just starting to learn your first programming language, what would confuse you less?
Jan 24 2011
parent reply foobar <foo bar.com> writes:
so Wrote:

 Look at this from a "It reads like English" prospective and not from a  
 "I'm an experienced c++ programmer and therefore already used to this  
 crap" perspective.
 In other words, if you were just starting to learn your first  
 programming language, what would confuse you less?

If i was starting to learn a language, everything would confuse me. I know C rules, i learned it with zero hostility to any other language, it is perfectly natural to me. Ok you said your natural language is not English, how is that you still speak it, could be because you just learned its basics? Which one is the Yoda now? Hebrew or English? Which one is natural? Or i should ask which one is natural for "you"?

Boy you missed the point by about 2.5 light years.. All I said is that Since D is English based (terminology, etc) it would make sense to follow a more English like word ordering in order to make the learning curve less steep. It obviously doesn't apply to someone who's already ahead of the learning curse such as yourself. There are Hebrew (and many other languages..) based programming languages out there and analogously it would make sense to strive for a Hebrew look and feel for those as well. Your argument boils down to something like "Who needs cars? I'm riding my horse Johnny since childhood..Feels natural to me" This has no relevance to an objective comparison between a car and a horse.
Jan 25 2011
parent reply foobar <foo bar.com> writes:
so Wrote:

 Boy you missed the point by about 2.5 light years..

This can go forever as long as one of us resist to simple reasoning and analogy, and the other one has the energy to continue.
 All I said is that Since D is English based (terminology, etc) it would  
 make sense to follow a more English like word ordering in order to make  
 the learning curve less steep.

We are not teaching PL to monkeys, though i am not sure if they would find this an issue. Math is another language and it is quite flexible, I don't see people that left to right oriented use "one add two equal three", while the others use "three equal one add two" and flaming the others. After you learn the damn rule (which is in the basics of any language), both equally natural.
 Your argument boils down to something like "Who needs cars? I'm riding
 my horse Johnny since childhood..Feels natural to me" This has no
 relevance to an objective comparison between a car and a horse.

No. And i can't get better than that so this discussion for me now pointless.

No one is flaming here, this is just an academic discussion and I'm sorry if you took offense. The subject of this discussion is the learning curve and *not* about teaching monkey to program. I'm simply stating that each language (programming or otherwise) has a learning curve which can be statistically measured for an average human being. Fact is that for the _same_ person it takes more time to learn C++ compared to other languages. So I'm *not* talking about how smart you need to be in order to learn C but rather how long will it take you to learn different programming languages and comparing _the_languages_ based on that metric. Math is actually a very good example: It takes many years to learn math (from first class to university) and therefore it has a very steep learning curve. Here's another perspective: A professor that teaches introduction to CS in first semester to students that never programmed before needs to choose a programing language. One of the criteria for choosing which language to use is of course the learning curve. I'm sure you know that not all universities choose c/c++ for this. In fact, I know of several universities that use scheme as that first programming language.
Jan 25 2011
parent reply foobar <foo bar.com> writes:
so Wrote:

 Here's another perspective:
 A professor that teaches introduction to CS in first semester to  
 students that never programmed before needs to choose a programing  
 language. One of the criteria for choosing which language to use is of  
 course the learning curve.
 I'm sure you know that not all universities choose c/c++ for this. In  
 fact, I know of several universities that use scheme as that first  
 programming language.

C++ is complex, it is obvious why it is harder to learn. Other languages don't have this mostly because they are not as powerful (i don't think i need to explain this). And this is what i mean, the reason its complexity, not the building blocks we are talking about. (again, i don't believe this syntax has anything to do with C++ being complex).

C++ is indeed complex and one of the reasons is its syntax (believe it or not). There was even an academic project to re-syntax C++ with the exact same semantics. Of course it's not the only cause of complexity in C++ but it is definitely one of the main ones. C++'s complexity has nothing to do with it's "power". D is as powerful and is less complex to use which is why we are here and not on the C++ dev mailing list. for example, D's classes/structs are way better than equivalent c++ code.
Jan 25 2011
parent foobar <foo bar.com> writes:
so Wrote:

 C++ is indeed complex and one of the reasons is its syntax (believe it  
 or not). There was even an academic project to re-syntax C++ with the  
 exact same semantics.
 Of course it's not the only cause of complexity in C++ but it is  
 definitely one of the main ones.

If that is the case, you are probably right, but still i can't quite grasp it.
 C++'s complexity has nothing to do with it's "power". D is as powerful  
 and is less complex to use which is why we are here and not on the C++  
 dev mailing list. for example, D's classes/structs are way better than  
 equivalent c++ code.

Well if you think the complexity has nothing to do with power, how can you use D as a counterexample? :)

"power" is a very subjective and problematic measure. We're discussing Turing complete languages and nothing prevents me from implementing a compiler/interpreter from one language to another thus gaining its "power". What we really want to talk is ease of expressiveness. C++ is more complex than D which means its harder to express oneself in c++. The difference is not that you can express something in one language but not in another (Both are Turing complete) but rather the *difficulty* of expressing the same thing in both languages. That difficulty makes for a steeper learning curve.
Jan 25 2011
prev sibling next sibling parent so <so so.do> writes:
 C++ style aka Yoda style:
 1. public double func(int input) const;
 2. const double func(int input);
 3. const double func(int input) const;

 VS.
 hypothetical left-to-right style:
 1. public const func (int input) -> (double);
 2.  func (int input) -> (const double);
 3. const func (int input) -> (const double);

 Which ordering makes for a more natural read?

For you or for me? :)
Jan 24 2011
prev sibling next sibling parent so <so so.do> writes:
 Look at this from a "It reads like English" prospective and not from a  
 "I'm an experienced c++ programmer and therefore already used to this  
 crap" perspective.
 In other words, if you were just starting to learn your first  
 programming language, what would confuse you less?

If i was starting to learn a language, everything would confuse me. I know C rules, i learned it with zero hostility to any other language, it is perfectly natural to me. Ok you said your natural language is not English, how is that you still speak it, could be because you just learned its basics? Which one is the Yoda now? Hebrew or English? Which one is natural? Or i should ask which one is natural for "you"?
Jan 24 2011
prev sibling next sibling parent so <so so.do> writes:
 C++ style aka Yoda style:
 1. public double func(int input) const;

Also, you can't do this in C++. Which was my point.
Jan 24 2011
prev sibling next sibling parent so <so so.do> writes:
 Also, you can't do this in C++.
 Which was my point.

Argh, hate it that you can't edit posts, ignore the second line.
Jan 24 2011
prev sibling next sibling parent so <so so.do> writes:
 Boy you missed the point by about 2.5 light years..

This can go forever as long as one of us resist to simple reasoning and analogy, and the other one has the energy to continue.
 All I said is that Since D is English based (terminology, etc) it would  
 make sense to follow a more English like word ordering in order to make  
 the learning curve less steep.

We are not teaching PL to monkeys, though i am not sure if they would find this an issue. Math is another language and it is quite flexible, I don't see people that left to right oriented use "one add two equal three", while the others use "three equal one add two" and flaming the others. After you learn the damn rule (which is in the basics of any language), both equally natural.
 Your argument boils down to something like "Who needs cars? I'm riding
 my horse Johnny since childhood..Feels natural to me" This has no
 relevance to an objective comparison between a car and a horse.

No. And i can't get better than that so this discussion for me now pointless.
Jan 25 2011
prev sibling next sibling parent so <so so.do> writes:
 Here's another perspective:
 A professor that teaches introduction to CS in first semester to  
 students that never programmed before needs to choose a programing  
 language. One of the criteria for choosing which language to use is of  
 course the learning curve.
 I'm sure you know that not all universities choose c/c++ for this. In  
 fact, I know of several universities that use scheme as that first  
 programming language.

C++ is complex, it is obvious why it is harder to learn. Other languages don't have this mostly because they are not as powerful (i don't think i need to explain this). And this is what i mean, the reason its complexity, not the building blocks we are talking about. (again, i don't believe this syntax has anything to do with C++ being complex).
Jan 25 2011
prev sibling parent so <so so.do> writes:
 C++ is indeed complex and one of the reasons is its syntax (believe it  
 or not). There was even an academic project to re-syntax C++ with the  
 exact same semantics.
 Of course it's not the only cause of complexity in C++ but it is  
 definitely one of the main ones.

If that is the case, you are probably right, but still i can't quite grasp it.
 C++'s complexity has nothing to do with it's "power". D is as powerful  
 and is less complex to use which is why we are here and not on the C++  
 dev mailing list. for example, D's classes/structs are way better than  
 equivalent c++ code.

Well if you think the complexity has nothing to do with power, how can you use D as a counterexample? :)
Jan 25 2011
prev sibling next sibling parent Torarin <torarind gmail.com> writes:
2011/1/24 foobar <foo bar.com>:
 This "problem" happens because D belongs to the C-family of languages which
puts the return type _before_ the function name.

 Languages that don't follow this syntactic convention (some would call it a
mistake) have it very consistent and readable:
 attribute funcName inputParams -> outputParams { body }
 This is the typical functional language design.

It is arguably more consistent to have the return type come first, as in variable declarations: int a = 4; int foo() { return 5; } Both "foo()" and "a" are now of type int. Torarin
Jan 24 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
foobar:

 This "problem" happens because D belongs to the C-family of languages which
puts the return type _before_ the function name.

Of course C++ has everything :-) See the trailing-return-type feature of C++0x: http://en.wikipedia.org/wiki/C%2B%2B0x#Alternative_function_syntax http://stackoverflow.com/questions/4523617/omit-return-type-in-c0x Bye, bearophile
Jan 24 2011
next sibling parent foobar <foo bar.com> writes:
bearophile Wrote:

 foobar:
 
 This "problem" happens because D belongs to the C-family of languages which
puts the return type _before_ the function name.

Of course C++ has everything :-) See the trailing-return-type feature of C++0x: http://en.wikipedia.org/wiki/C%2B%2B0x#Alternative_function_syntax http://stackoverflow.com/questions/4523617/omit-return-type-in-c0x Bye, bearophile

Of course they added it, they also experienced similar problems with the current syntax since it is out of place in the reading order.
Jan 24 2011
prev sibling parent so <so so.do> writes:
 Of course C++ has everything :-) See the trailing-return-type feature of  
 C++0x:
 http://en.wikipedia.org/wiki/C%2B%2B0x#Alternative_function_syntax
 http://stackoverflow.com/questions/4523617/omit-return-type-in-c0x

 Bye,
 bearophile

Now i am completely lost, i can't see any connection at all!
Jan 24 2011