const/immutable member functions

[Jens Mueller]

Jonathan M Davis wrote:
> On Monday 24 January 2011 13:52:49 Jens Mueller wrote:
> > Jonathan M Davis wrote:
> > > On Monday 24 January 2011 12:08:29 Don wrote:
> > > > Steven Schveighoffer wrote:
> > > > > On Mon, 24 Jan 2011 13:36:36 -0500, bearophile
> > > > > 
> > > > > <bearophileHUGS at 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 afterwards always works. Putting it before
> > > > doesn't always work, due to compiler bugs (for example, prefix 'pure'
> > > > doesn't work for inner functions).
> > > 
> > > There there is a bug that attributes on constructors don't show up in
> > > generated .di files if they're on the right.
> > > 
> > > I think that the real problem with putting them all on the right is that
> > > attributes such as static, public, and private are on the left in other
> > > languages, so it would be really weird to require that they be on the
> > > right. Still, it might be worth it.
> > 
> > Can't one have only the type qualifiers on the right? I mean it's only
> > confusing for those.
> > pure/nothrow int foo();
> > causes no confusion at all.
> > The access qualifiers also work fine in the beginning. On the right they
> > won't even compile.
> 
> I'm surprised that they don't work on the right. The argument for allowing const 
> on the left-hand side has always been consistency - that all function attributes 
> work the same. If that's not the case, then it seems to me like a definite 
> argument for disallowing const on the left.

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

Jens