const/immutable member functions

Jens Mueller jens.k.mueller at gmx.de
Mon Jan 24 13:52:49 PST 2011


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.

Jens


More information about the Digitalmars-d mailing list