const/immutable member functions

[Jens Mueller]

Jonathan M Davis wrote:
> On Tuesday 25 January 2011 01:45:49 Jens Mueller wrote:
> > 
> > I do not know what are you referring to when you say function attributes.
> > I distinguish the following:
> > type qualifiers: const, immutable, maybe also inout
> > function attributes: pure, nothrow
> > storage class: ref, in, out, static
> > access qualifiers: private, package, protected, public, export
> > 
> > Storage class and access qualifies should go left only in my opinion and
> > that's how dmd behaves.
> > Function attributes can go left and right and I think there is nothing
> > wrong with allowing that because there is no confusion. Even though I
> > like them to be right as well. But this is matter of style.
> > There is only confusion for type qualifies. Namely does the qualifier
> > apply to the return type or the function (better said the type of this).
> > Now it is consistent in the sense that
> > const:
> >     int foo();
> > const {
> >     int foo();
> > }
> > const int foo();
> > 
> > all mean the same. And Walter seems to be unsure whether forbidding
> > const void foo() is worth the trouble, isn't it?
> > I see and felt the pain for newcomers to decipher the meaning of
> > const void foo();
> > I see two options:
> > Either we clarify the documentation (e.g. examples) to help newcomers or
> > we fix it in the front end. Picking the second option means to provide a
> > patch and send it to review. Picking the first option means improving
> > http://www.digitalmars.com/d/2.0/const3.html
> 
> Anything that modifies a function could be considered a function attribute: 
> public, static, nothrow, pure, @property, const, etc. Something that modifies the 
> return value of a function or a function parameter isn't a function attribute. 

You want to make a distinction regarding the modification. Those ones
are called function attributes because they change a function in that
regard. I'm not sure whether this clarifies things.
I just think const/immutable as type qualifiers and you can apply those
to member functions because the type of this object can be qualified as
const/immutable.

> In the past, Walter's argument for const working as it is is that it is 
> consistent with the other function attributes and that requiring that it be on 
> the right would be inconsistent.

I didn't have that impression reading the mentioned bug reports. It
seems there is more that I'm missing.

Jens