const/immutable member functions

[Jonathan M Davis]

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.

- Jonathan m Davis