www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Normalizing Const Syntax.

reply "Scott S. McCoy" <tag cpan.org> writes:
I've brought this up several times within threads, and not gotten any
responses.  So I thought I would make it a thread of its own.  How about
normalizing the syntax of const?

private const int foo;
public const const(int) bar () { return foo; }

In the above example, the behavior of the keyword "const" is relatively
schizophrenic.  const is listed as a part of the storage class for foo,
and then as an access qualifier for bar(), with the same syntax.  While
it should be noted that this type of behavior is suitable with static,
but that is because the nature of static is different.  static is both a
storage class and an access qualifier, and it behaves fine as such.  

However the "transitive const" definition makes const no longer a
storage class.  const is now an attribute of the value type, which is
what makes it transitive.  Granted, this type attribute does change the
behavior of storage, but that doesn't magically make its behavior
consistent with storage-class keywords such as static, or extern.  It's
a different class of concept.

It would seem more consistent with the essence of our new const
definition if const was always an attribute of the type, when associated
with an identifier.  So the syntax should reflect this, as per the
following example.

private const(int) _foo;
public const const(int) foo () { return _foo; }

This would also mean that:

private const int foo;

could retain it's previous definition, which is a part of what's
making people so frustrated about const.  Since const is listed in the
storage-class part of the declaration, const as a storage class could
be possible.  Alternatively, const as a storage class could be a syntax
error, if we really want to get rid of the concept entirely and not have
two consts floating around.  This would make porting D1 code to D2
easier, since it would either 1) Work as expected, or 2) Just not work
and the compiler could tell you about it.

Cheers,
	Scott S. McCoy
Apr 08 2008
next sibling parent Georg Wrede <georg nospam.org> writes:
Scott S. McCoy wrote:
 I've brought this up several times within threads, and not gotten any
 responses.  So I thought I would make it a thread of its own.  How about
 normalizing the syntax of const?
 
 private const int foo;
 public const const(int) bar () { return foo; }
 
 In the above example, the behavior of the keyword "const" is relatively
 schizophrenic.  const is listed as a part of the storage class for foo,
 and then as an access qualifier for bar(), with the same syntax.  While
 it should be noted that this type of behavior is suitable with static,
 but that is because the nature of static is different.  static is both a
 storage class and an access qualifier, and it behaves fine as such.  

Suppose one has a new language to learn, and the syntax would be inconsistent between, say, storage class, access qualifier, and type attribute. How is one supposed to learn the difference? While those who are familiar with a language may not "see" this, it is a severe stumbling block for those who really try to understand things. Ahd that's the kind of programmers we want to D.
 However the "transitive const" definition makes const no longer a
 storage class.  const is now an attribute of the value type, which is
 what makes it transitive.  Granted, this type attribute does change the
 behavior of storage, but that doesn't magically make its behavior
 consistent with storage-class keywords such as static, or extern.  It's
 a different class of concept.
 
 It would seem more consistent with the essence of our new const
 definition if const was always an attribute of the type, when associated
 with an identifier.  So the syntax should reflect this, as per the
 following example.
 
 private const(int) _foo;
 public const const(int) foo () { return _foo; }
 
 This would also mean that:
 
 private const int foo;
 
 could retain it's previous definition, which is a part of what's
 making people so frustrated about const.  Since const is listed in the
 storage-class part of the declaration, const as a storage class could
 be possible.  Alternatively, const as a storage class could be a syntax
 error, if we really want to get rid of the concept entirely and not have
 two consts floating around.  This would make porting D1 code to D2
 easier, since it would either 1) Work as expected, or 2) Just not work
 and the compiler could tell you about it.
 
 Cheers,
 	Scott S. McCoy
 
 
 

Apr 08 2008
prev sibling next sibling parent reply Graham St Jack <Graham.StJack internode.on.net> writes:
On Tue, 08 Apr 2008 15:51:22 -0700, Scott S. McCoy wrote:

 I've brought this up several times within threads, and not gotten any
 responses.  So I thought I would make it a thread of its own.  How about
 normalizing the syntax of const?
 
 private const int foo;
 public const const(int) bar () { return foo; }
 
 In the above example, the behavior of the keyword "const" is relatively
 schizophrenic.  const is listed as a part of the storage class for foo,
 and then as an access qualifier for bar(), with the same syntax.  While
 it should be noted that this type of behavior is suitable with static,
 but that is because the nature of static is different.  static is both a
 storage class and an access qualifier, and it behaves fine as such.
 
 However the "transitive const" definition makes const no longer a
 storage class.  const is now an attribute of the value type, which is
 what makes it transitive.  Granted, this type attribute does change the
 behavior of storage, but that doesn't magically make its behavior
 consistent with storage-class keywords such as static, or extern.  It's
 a different class of concept.
 
 It would seem more consistent with the essence of our new const
 definition if const was always an attribute of the type, when associated
 with an identifier.  So the syntax should reflect this, as per the
 following example.
 
 private const(int) _foo;
 public const const(int) foo () { return _foo; }
 
 This would also mean that:
 
 private const int foo;
 
 could retain it's previous definition, which is a part of what's making
 people so frustrated about const.  Since const is listed in the
 storage-class part of the declaration, const as a storage class could be
 possible.  Alternatively, const as a storage class could be a syntax
 error, if we really want to get rid of the concept entirely and not have
 two consts floating around.  This would make porting D1 code to D2
 easier, since it would either 1) Work as expected, or 2) Just not work
 and the compiler could tell you about it.
 
 Cheers,
 	Scott S. McCoy

I agree that the present syntax is a problem, but I'm not sure how your suggestion fixes the problem. The two alternatives that make sense to me are: const ReturnType const method_name(); const ReturnType method_name() const; where in each case the first const applies to the return type and the second to the method.
Apr 08 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
I think it would be enormously wrong for

    const int x;

and

    const(int) x;

to mean two entirely different things (which I think was part of what
Scott was suggesting). But I do agree with all the rest of it.

So here's something to think about. Consider the following code:

    class C
    {
        const
        {
            T x;
            T f() { ... }
        }
    }

What would be the most intuitive meaning of f's const. Would it be:
(a) the function expects "this" to be const
(b) the function returns a const(T)
(c) both of the above simultaneously
(d) none of the above

I think (b).

In D2.012, the actual meaning is (a), but pretty much everyone agrees
that's not intuitive.
Apr 08 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Janice Caron wrote:
 I think it would be enormously wrong for
 
     const int x;
 
 and
 
     const(int) x;
 
 to mean two entirely different things (which I think was part of what
 Scott was suggesting). But I do agree with all the rest of it.
 
 So here's something to think about. Consider the following code:
 
     class C
     {
         const
         {
             T x;
             T f() { ... }
         }
     }
 
 What would be the most intuitive meaning of f's const. Would it be:
 (a) the function expects "this" to be const
 (b) the function returns a const(T)
 (c) both of the above simultaneously
 (d) none of the above
 
 I think (b).

You could be right. But either way, I object to the heavy use of non-local attribute modifiers that change the meaning of statements far from where they are written. So even though it might be "cute" to put 'static' or 'const' in a big block around a big chunk of functions, I think doing such things is bad style. I'm not a big Java fan, but I think maybe Java might have had it right on this one. When I look at a big class in D I'm forever trying to figure out whether some unlabeled method is public/private/protected. And several times I've been bitten by not noticing an innocuous little "extern(C):" stuck at the top of a file.
 In D2.012, the actual meaning is (a), but pretty much everyone agrees
 that's not intuitive.

Indeed. I also don't like the idea that lots of extra parenthesis will be forced upon us just to allow something which I think is of dubious value to begin with. I.e., this should return a const value, not have a const 'this': const Bar Foo() But with the current regime that has to get some extra parens to express that. Too many parens in a signature makes it hard to read, so I really don't want "const(Bar) Foo()" to be the norm. --bb
Apr 09 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Bill Baxter wrote:
 Indeed.  I also don't like the idea that lots of extra parenthesis
 will be forced upon us just to allow something which I think is of
 dubious value to begin with.  I.e., this should return a const value,
 not have a const 'this':
     const Bar Foo()
 But with the current regime that has to get some extra parens to
 express that.  Too many parens in a signature makes it hard to read,
 so I really don't want "const(Bar) Foo()" to be the norm.

 --bb

the problem with the current syntax IMHO is that we want to specify several different const meanings all at the same place in the code: - constancy of the return type - constancy of the this pointer (for methods) - "constancy" of the code itself - i.e pure functions to solve this we need to either, a) have a different name for each of those (this is partly so with the use of "pure") // const_this & const_return are placeholders for 2 different keywords. ---> pure const_this const_return int func(int a, int b); or b) rearrange the syntax so each meaning has its own place. in a perfect world that would be something like: const func(const this, const int a, int b) : const int; // first const means pure, last const is for return type. that even reduces the keyword count! (no need for pure) but... that will not happen because it's too big a change in syntax for D. at least i hope the "const this" above could be considered as it also would be extensible for another use case promised for D2 - extensible classes. basically, of all the other rearrangement of function declaration ideas on the NG I liked the most the one Janice, i think, suggested of using const(this).this makes very clear what is const, however it adds another pair of parens which is confusing. so my personal conclusion is - why have two pairs of parens? lets unite them to the following: int a(const this, const int a); which is very clear on its intent, IMO. Questions? Suggestions? --Yigal
Apr 09 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Janice Caron wrote:
 However, there is a reason why Walter has not made const-at-the-front
 illegal, which is that /he likes it/. And so far as I can gather, the
 reason that he likes it is because it means he is able to write
 
     const
     {
         /* lots of functions */
     }

Which is a horrible syntax in my opinion. Something to be avoided rather than something to bend over backwards trying to support. Why should a big block-o-const only affect the 'this' arguments of functions inside of it? Not to mention, the bigger the block-o-const, the more likely it is that someone reading the code will not see the const label. It's a bad idea in my opinion. --bb
Apr 10 2008
parent reply "Koroskin Denis" <2korden+dmd gmail.com> writes:
On Thu, 10 Apr 2008 17:53:56 +0400, Bill Baxter  
<dnewsgroup billbaxter.com> wrote:

 Janice Caron wrote:
 However, there is a reason why Walter has not made const-at-the-front
 illegal, which is that /he likes it/. And so far as I can gather, the
 reason that he likes it is because it means he is able to write
      const
     {
         /* lots of functions */
     }

Which is a horrible syntax in my opinion. Something to be avoided rather than something to bend over backwards trying to support. Why should a big block-o-const only affect the 'this' arguments of functions inside of it? Not to mention, the bigger the block-o-const, the more likely it is that someone reading the code will not see the const label. It's a bad idea in my opinion. --bb

The same could be said for private or static methods. Do you propose we should get rid of these, too? IMO, it's a matter of style. You can but, you don't have to use that syntax.
Apr 10 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Koroskin Denis wrote:
 On Thu, 10 Apr 2008 17:53:56 +0400, Bill Baxter 
 <dnewsgroup billbaxter.com> wrote:
 
 Janice Caron wrote:
 However, there is a reason why Walter has not made const-at-the-front
 illegal, which is that /he likes it/. And so far as I can gather, the
 reason that he likes it is because it means he is able to write
      const
     {
         /* lots of functions */
     }

Which is a horrible syntax in my opinion. Something to be avoided rather than something to bend over backwards trying to support. Why should a big block-o-const only affect the 'this' arguments of functions inside of it? Not to mention, the bigger the block-o-const, the more likely it is that someone reading the code will not see the const label. It's a bad idea in my opinion. --bb

The same could be said for private or static methods. Do you propose we should get rid of these, too? IMO, it's a matter of style. You can but, you don't have to use that syntax.

Those are different because private or static does indeed apply to the methods as a whole, and not just one particular parameter of the methods. But anyway, I have started to loathe all the nonlocal ways to set protection levels, because I'm forever looking up and down in the class to try to figure out what's public and what's not. I'm not going to say we have to get rid of those, but there better be a really compelling reason to add more. --bb
Apr 10 2008
parent reply Georg Wrede <georg nospam.org> writes:
Bill Baxter wrote:
 Koroskin Denis wrote:
 Bill Baxter wrote:
 Janice Caron wrote:

 However, there is a reason why Walter has not made const-at-the-front
 illegal, which is that /he likes it/. And so far as I can gather, the
 reason that he likes it is because it means he is able to write
      const
     {
         /* lots of functions */
     }

Which is a horrible syntax in my opinion. Something to be avoided rather than something to bend over backwards trying to support. Why should a big block-o-const only affect the 'this' arguments of functions inside of it?



That is a good point.
 Not to mention, the bigger the block-o-const, the more likely it 
 is that someone reading the code will not see the const label.

The same could be said for private or static methods. Do you propose we should get rid of these, too? IMO, it's a matter of style. You can but, you don't have to use that syntax.

Those are different because private or static does indeed apply to the methods as a whole, and not just one particular parameter of the methods. But anyway, I have started to loathe all the nonlocal ways to set protection levels, because I'm forever looking up and down in the class to try to figure out what's public and what's not. I'm not going to say we have to get rid of those, but there better be a really compelling reason to add more.

Well, there are a lot of things where one can choose the wrong way of writing code. And I believe the attribute { definition; definition; ... } style is meant for a long bunch of one-line definitions. Only an idiot would spread the attribute over several pages. This of course means that if one has a class or simply a list of definitions, that starts to grow multi-line, there comes a point where the attribute envelope should be deleted and the definitions attributed individually. (A good text editor should do this, btw.) Deciding up-front whether to use the envelope or individual attributions is like deciding up-front whether to use OO-only or procedural-only. Not very practical.
Apr 10 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Georg Wrede wrote:

 Only an idiot would spread the attribute over several pages.
 
 This of course means that if one has a class or simply a list of 
 definitions, that starts to grow multi-line, there comes a point where 
 the attribute envelope should be deleted and the definitions attributed 
 individually. (A good text editor should do this, btw.)

Good point. A rule of thumb may be that the attribute should never be more than 1/2 a page of code away from where it applies. If it starts to get more than that, then you should switch your style (perhaps to labeling every function a la Java.) --bb
Apr 10 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bill Baxter wrote:
 Georg Wrede wrote:
 
 Only an idiot would spread the attribute over several pages.

 This of course means that if one has a class or simply a list of 
 definitions, that starts to grow multi-line, there comes a point where 
 the attribute envelope should be deleted and the definitions 
 attributed individually. (A good text editor should do this, btw.)

Good point. A rule of thumb may be that the attribute should never be more than 1/2 a page of code away from where it applies. If it starts to get more than that, then you should switch your style (perhaps to labeling every function a la Java.) --bb

Proponents of attribute blocks might say that one of the intended uses of it is when you have lots of declarations (ie, more that 1/2 pages of code). Anyways, I'm also not a fan of attribute blocks. For one reason, because I like each definition to be self-contained. Second, because I like to group related functions together, and often these groups have mixed protections (private, public, protected, etc.). If I was to use attribute blocks I would have to bundle all private methods of the scope together, all public methods together, etc.. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Apr 27 2008
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 10 Apr 2008 15:03:30 +0200, Janice Caron <caron800 googlemail.com>  
wrote:

     const(this)
     {
         /* lots of functions */
     }

 Only something-at-the-front can do this.

Could we not do like this: { /* lots of functions */ } const; :p
Apr 10 2008
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 09/04/2008, Yigal Chripun <yigal100 gmail.com> wrote:
  so my personal conclusion is - why
  have two pairs of parens? lets unite them to the following:
  int a(const this, const int a);
  which is very clear on its intent, IMO.

  Questions? Suggestions?

I don't have any particular problem with that syntax, however, it's no better or worse than any other possiblity. The following all seem to be equally acceptable: (1) ReturnType f(Params...) const (2) ReturnType f(const this, Params...) (3) ReturnType const f(Params...) Of these, (1) is *already legal syntax*, so it's not like we need something to replace it. (Yours is option 2) Indeed, the simplest answer of all would be just to get rid of const-at-the-front, leaving const-at-the-back as the way to do things. However, there is a reason why Walter has not made const-at-the-front illegal, which is that /he likes it/. And so far as I can gather, the reason that he likes it is because it means he is able to write const { /* lots of functions */ } So you see, part of the purpose of the const(this) proposal is to keep Walter happy. It means that he will still be able to do const(this) { /* lots of functions */ } Only something-at-the-front can do this. So, const(this) is an attempt to simultaneously (a) remove the current unintuitive syntax, and (b) keep Walter happy. It's also consistent with D-style in that D already has attributes like extern(C) and version(Windows), so const(this) would be right at home. And of course - the bonus is that const R f(...) can have its intuitive meaning of "f returns a const(R)". (Of course, if const(this)-at-the-front ever replaces const-at-the-front, then the question of whether to allow const-at-the-back returns to haunt us! :-))
Apr 10 2008
prev sibling next sibling parent reply "Hans W. Uhlig" <huhlig clickconsulting.com> writes:
Scott S. McCoy wrote:
 On Wed, 2008-04-09 at 01:08 +0000, Graham St Jack wrote:
 I agree that the present syntax is a problem, but I'm not sure how
 your 
 suggestion fixes the problem.

By normalizing the syntax. if const is transitive, then it needs to be differentiated from other types of storage classes such a static. My solution simply takes the existing, currently defined syntax for differentiating between them and makes it mandatory for all const-typed identifiers. const(int) foo how becomes the way of saying a const int. Rather than trying to reshape the syntax (which I also tried to do, but found difficult in a number of ways) I thought maybe a quicker, and easier to get accepted route would just be to re-purpose the existing syntax. In fact, this syntax already exists...I'm just suggesting removing the other, or removing it's newer definition.
 The two alternatives that make sense to me are:

 const ReturnType const method_name();

 const ReturnType method_name() const;

Right, and I've seen this suggestion. Actually, I'm not sure any of this solves the problem. The real issue here is that we just have too many damn things to say with the word const. Maybe we should separate the concept of a const method and a const identifier. After all, the difference between the const and invariant method definitions is...well...slim: """ Invariant member functions are guaranteed that the object and anything referred to by the this reference is invariant. """ """ Const member functions are functions that are not allowed to change any part of the object through the member function's this reference. """ Isn't the goal here just that the member function doesn't modify anything? And why do invariant member functions even need to exist? (Are we really going to use them?). Maybe we could come up with a base-line that works for member functions between the two, and ditch the use of the keyword "const" for method declarations entirely. Then we could have a special access class which defines that the function may be invoked from the context of a const *or* invariant instance. Naturally, an invariant class means nothing can be modifiable, but I can't imagine why "doesn't modify anything in the this reference" doesn't suffice for functions in an invariant context. Cheers, Scott S. McCoy

Ok, Jumping off a limb here. Perhaps a slight variation to the C declaration might be in order, since I know that multiple return values are wanted, a simple and readable syntax for inheritance is needed (using : as an inheritor does not make code more readable) try this out and see if it makes it clearer <modifiers,...> <identifier> <properties,...> {...} such that: const foo(const int, const double) throws barExtension returns const int, const float { // ... code ... } same for classes: const class foo extends bar { const int x; pure foo(const int, const double) returns invariant string; // ... more code ... } (Note: is used as a divider because no one uses it for anything in programming and I didn't want to start an argument over : or | or ; or any other punctuation being used elsewhere and being bad, quite possible punctuation wouldn't be neccessary) It looks like a hideous cross between java and visual basic but it is clean, readable, simple to machine parse(I think) and descriptive. using slightly longer keywords makes a language a little more verbose, but it also makes it readable. if you want to use punctuation for everything you get what happened to perl when someone got a little too creative `$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:, %)=( $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++; $_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++ ;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
Apr 11 2008
parent reply Georg Wrede <georg nospam.org> writes:
Hans W. Uhlig wrote:
 same for classes:
 
 const class foo  extends bar {
     const int x;
     pure foo(const int, const double)  returns invariant string;
     // ... more code ...
 }
 
 (Note:  is used as a divider because no one uses it for anything in 
 programming and I didn't want to start an argument over : or | or ; or 
 any other punctuation being used elsewhere and being bad, quite possible 
 punctuation wouldn't be neccessary)

It's not used because it's not found in the american keyboard.
Apr 11 2008
parent "Hans W. Uhlig" <huhlig clickconsulting.com> writes:
Georg Wrede wrote:
 Hans W. Uhlig wrote:
 same for classes:

 const class foo  extends bar {
     const int x;
     pure foo(const int, const double)  returns invariant string;
     // ... more code ...
 }

 (Note:  is used as a divider because no one uses it for anything in 
 programming and I didn't want to start an argument over : or | or ; or 
 any other punctuation being used elsewhere and being bad, quite 
 possible punctuation wouldn't be neccessary)

It's not used because it's not found in the american keyboard.

as listed, it was not meant to be a suggestion for punctuation mearly a placeholder. : would work just as well.
Apr 11 2008
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 11/04/2008, Hans W. Uhlig <huhlig clickconsulting.com> wrote:
  as listed, it was not meant to be a suggestion for punctuation mearly a
 placeholder. : would work just as well.

The word "which" in place of that placeholder would make all of those examples very readable.
Apr 13 2008
prev sibling next sibling parent "Scott S. McCoy" <tag cpan.org> writes:
On Wed, 2008-04-09 at 01:08 +0000, Graham St Jack wrote:
 
 
 I agree that the present syntax is a problem, but I'm not sure how
 your 
 suggestion fixes the problem.

By normalizing the syntax. if const is transitive, then it needs to be differentiated from other types of storage classes such a static. My solution simply takes the existing, currently defined syntax for differentiating between them and makes it mandatory for all const-typed identifiers. const(int) foo how becomes the way of saying a const int. Rather than trying to reshape the syntax (which I also tried to do, but found difficult in a number of ways) I thought maybe a quicker, and easier to get accepted route would just be to re-purpose the existing syntax. In fact, this syntax already exists...I'm just suggesting removing the other, or removing it's newer definition.
 
 The two alternatives that make sense to me are:
 
 const ReturnType const method_name();
 
 const ReturnType method_name() const;
 

Right, and I've seen this suggestion. Actually, I'm not sure any of this solves the problem. The real issue here is that we just have too many damn things to say with the word const. Maybe we should separate the concept of a const method and a const identifier. After all, the difference between the const and invariant method definitions is...well...slim: """ Invariant member functions are guaranteed that the object and anything referred to by the this reference is invariant. """ """ Const member functions are functions that are not allowed to change any part of the object through the member function's this reference. """ Isn't the goal here just that the member function doesn't modify anything? And why do invariant member functions even need to exist? (Are we really going to use them?). Maybe we could come up with a base-line that works for member functions between the two, and ditch the use of the keyword "const" for method declarations entirely. Then we could have a special access class which defines that the function may be invoked from the context of a const *or* invariant instance. Naturally, an invariant class means nothing can be modifiable, but I can't imagine why "doesn't modify anything in the this reference" doesn't suffice for functions in an invariant context. Cheers, Scott S. McCoy
Apr 08 2008
prev sibling next sibling parent "Scott S. McCoy" <tag cpan.org> writes:
On Thu, 2008-04-10 at 14:03 +0100, Janice Caron wrote:
 However, there is a reason why Walter has not made const-at-the-front
 illegal, which is that /he likes it/. And so far as I can gather, the
 reason that he likes it is because it means he is able to write
 
     const
     {
         /* lots of functions */
     }
 

That, and when compared to the rest of the language syntax, it makes a whole lot of sense. However; the problem I think is mostly in the keyword.
Apr 10 2008
prev sibling parent "Scott S. McCoy" <tag cpan.org> writes:
I liked that about D actually, the attrition of syntax from other
languages provides flexibility regardless of your personal preference.

Some people like to type it out explicitly, so two pages of private
methods later they don't forget what they were looking at (or after
leaving and coming back to the computer, for instance).

Alot of these people (although, not all of them I'm afraid) *also*
segment their public and private members, although not with the local
syntax, but just at some point in the file.

Maintaining largely compatible syntax and hence concepts across
languages like Java, C# and Ferite, means that D is easy to adopt.  And
the same is true for maintaining the C++-ish syntax, of having public:
local labels.

I think the problem with const is just what we've identified earlier in
the thread, the keyword for "this method doesn't change anything" should
just probably not be the same keyword as "this is a read only reference,
and so are it's descendants".

Additionally, I'd like to defend the rationale behind my original
proposal.  I was following this, apparently already existing definition
of a type annotation:

annotation(type);

Which means:

const(int), makes "const" an annotation, or attribute if you will, of
the type.

Really, type attributes or annotations should have some completely
different syntax, if you ask me.  Because this existing syntax makes
"const" more like a special function, similar to "cast()" which is
already kind of mind-boggling.  Something along the lines of a marker
which asthetically provides an extension of that type.

int : const foo = blah.

public const int:const foo (int:const bar); 

might be adequate, although it's asthetically quite similar to janice's
previous suggestion of saying that the const must come after the type,
it has slightly different and more consistent semantics.  It implies
that a type could be defined as:

<type> ::= <type-keyword> |
           <type-keyword> <annotation-marker> <annotation-keyword>
<annotation-marker> ::= ":"
<annotation-keyword> ::= "const" | "invariant" ;; More to be defined,
possibly.

And this undoes the schizophrenia of how to refer to const, since now
"const" is perfectly safe as an access qualifier.

<access-qualifier> ::= "public" | "private" | "package" | "protected" | 
<static>           ::= "static"
<reference-access> ::= "const" | "invariant"
<access-level>     ::= <access-qualifier> |
                       <access-qualifier> <access-level>

<method-access>    ::= <access-level> <reference-access> <type> |
                       <access-level> <static> <type> |
                       <access-level> <type>

This syntax, whilst it may diverge from what currently exists in D,
introduces the divergent syntax in a divergent fashion which makes the
divergent concept of the redefined const suddenly more consistent, in my
humble opinion.

Again, I'm all for backward compatability, so this would mean that, you
could again re-introduce a more backwardly-compatible const, or
outwardly disable it, by making the following syntax "legal" or
"illegal" respectively and retaining or completely removing the previous
const definition.

private const int : const foo;

Although it's awkwardly redundant if retained, atleast it enables easier
D1->D2 porting, and if lost instead of retained, it provides a clearer
migration path for those who were previously relying on the older
definition of const and really should just remove it for D2.  Rather
than hiding the new behavior behind the older definition.

Cheers,
	Scott S. McCoy

On Fri, 2008-04-11 at 00:09 +0900, Bill Baxter wrote:
 Koroskin Denis wrote:
 On Thu, 10 Apr 2008 17:53:56 +0400, Bill Baxter 
 <dnewsgroup billbaxter.com> wrote:
 
 Janice Caron wrote:
 However, there is a reason why Walter has not made const-at-the-front
 illegal, which is that /he likes it/. And so far as I can gather, the
 reason that he likes it is because it means he is able to write
      const
     {
         /* lots of functions */
     }

Which is a horrible syntax in my opinion. Something to be avoided rather than something to bend over backwards trying to support. Why should a big block-o-const only affect the 'this' arguments of functions inside of it? Not to mention, the bigger the block-o-const, the more likely it is that someone reading the code will not see the const label. It's a bad idea in my opinion. --bb

The same could be said for private or static methods. Do you propose we should get rid of these, too? IMO, it's a matter of style. You can but, you don't have to use that syntax.

Those are different because private or static does indeed apply to the methods as a whole, and not just one particular parameter of the methods. But anyway, I have started to loathe all the nonlocal ways to set protection levels, because I'm forever looking up and down in the class to try to figure out what's public and what's not. I'm not going to say we have to get rid of those, but there better be a really compelling reason to add more. --bb

Apr 11 2008