Normalizing Const Syntax.

[Hans W. Uhlig]

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

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