const/immutable member functions

Jonathan M Davis jmdavisProg at gmx.com
Tue Jan 25 02:38:09 PST 2011


On Tuesday 25 January 2011 01:45:49 Jens Mueller wrote:
> 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

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. 
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.

- Jonathan M Davis


More information about the Digitalmars-d mailing list