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.

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

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.

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

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.

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

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

`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`

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.

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.

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.