On Thu, May 08, 2014 at 01:59:58AM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
> On Thu, 08 May 2014 07:29:08 +0000
> bearophile via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
> wrote:
>
> > Jonathan M Davis:
> >
> > > ultimately, this sort of thing pretty much always ends up being
> > > highly subjective.
FWIW, for very long function signatures I write it this way:
const(T)[] myVeryLongFunction(T)(const(T)[] arr,
int x,
int y,
int z,
ExtraArgs extraArgs)
pure @safe nothrow
if (is(T : int) &&
someOtherLongCriteria!T &&
yetMoreVeryLongCriteria!T)
{
...
}
> > But please put the const/immutable of methods on the right:
> >
> > struct Foo {
> > void bar1() const {} // Good
> > const void bar2() {} // Bad
> > }
>
> Well, that's one case where there's actually an objective reason to
> put it on the right due to one of the flaws in the language - that
> it's the one place that const inconsistently does not apply to the
> type immediately to its right (though it's consistent with how
> attributes are applied to the function itself - just not consistent
> with variables).
Due to this flaw, I've stopped writing "const T" completely -- now I
only ever write "const(T)". Besides, there is also the ambiguity between
const(T)[] and const(T[]), so I regard writing const without parens
(const T[]) as a bad practice in D.
> It's also because of this that I favor putting most attributes on the
> right (though that's subjective, unlike with const). I only put
> attributes on the left if they're on the left in C++ or Java (e.g.
> static, public, or final). Everything else goes on the right.
[...]
Ditto. I think this is the closest we can come to consistency given the
current language.
T
--
My program has no bugs! Only undocumented features...
