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