Jonathan M Davis:

> ultimately, this sort of
> thing pretty much always ends up being highly subjective.

But please put the const/immutable of methods on the right:

struct Foo {
    void bar1() const {} // Good
    const void bar2() {} // Bad
}

Bye,
bearophile

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

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.

Unfortunately, making this consistent by doing something like enforcing that all function attributes go on the right would then be inconsistent with other languages with regards to the attributes that they have which go on the left, so I don't know how we could have gotten it completely right. No matter which way you go, it's inconsistent in one way or another. If it were up to me, I'd probably enforce that all attributes which could be ambiguous go on the right but that all others could go on either side, but Walter has never liked that idea. So, we're stuck with arguing that everyone should put them on the right by convention in order to avoid the ambiguity.

- Jonathan M Davis

Jonathan M Davis:

> Unfortunately, making this consistent by doing something like enforcing that
> all function attributes go on the right would then be inconsistent with other
> languages with regards to the attributes that they have which go on the left,

This is a job for a Lint. like DScanner :-)

Bye,
bearophile

On Thu, 08 May 2014 09:30:38 +0000
bearophile via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> Jonathan M Davis:
>
> > Unfortunately, making this consistent by doing something like
> > enforcing that
> > all function attributes go on the right would then be
> > inconsistent with other
> > languages with regards to the attributes that they have which
> > go on the left,
>
> This is a job for a Lint. like DScanner :-)

Sure, that could point out that putting const or the left is bug-prone and warn you that you should change it, but while it's not really possible to have a fully consistent design with regards to function attributes, I still think that allowing const on the left is simply a bad design decision. A linter is then just a way to help you work around that bad design decision.

- Jonathan M Davis

Jonathan M Davis:

> I still think that allowing const on the left is simply a
> bad design decision.

I opened a request on this, and it was closed down :-)

Bye,
bearophile

On Thu, 08 May 2014 10:27:17 +0000
bearophile via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> Jonathan M Davis:
>
> > I still think that allowing const on the left is simply a bad design decision.
>
> I opened a request on this, and it was closed down :-)

I know. Walter doesn't agree that it was a bad decision. He thinks that being consistent with the other function attributes and letting them all be on both sides of the function is more important, but given the fact that that's highly error-prone for const and immutable, I definitely think that it was a bad decision. Unfortunately, we're stuck with it, because Walter doesn't agree, and I don't expect that anyone is going to be able to convince him.

- Jonathan M Davis

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

On Thu, 8 May 2014 07:32:52 -0700
"H. S. Teoh via Digitalmars-d-learn"
<digitalmars-d-learn@puremagic.com> wrote:

> 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)
>   {
>       ...
>   }

That's that I do with the params, but I'd still put the attributes to the right of the last param rather than on their own line. I don't think that I'd _ever_ put attributes on their own line. But as always, it's all quite subjective, and everyone seems to prefer something at least slightly different.

- Jonathan M Davis

H. S. Teoh:

> 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)
> 	{
> 		...
> 	}

You also need the pre&post-conditions :-)

Bye,
bearophile

On Thu, May 08, 2014 at 02:50:54PM +0000, bearophile via Digitalmars-d-learn wrote:
> H. S. Teoh:
> 
> >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)
> >	{
> >		...
> >	}
> 
> You also need the pre&post-conditions :-)
[...]

I actually had them in my first draft. :)

	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)
	in {
		assert(x >= 0 && x < 5);
		assert(y >= 0 && y < 5);
		assert(z >= 0 && z < 5);
	}
	out(result)
	{
		assert(result[0] >= 0 && result[0] < 5);
		assert(result[1] >= 1 && result[1] < 6);
		assert(result[2] >= 2 && result[2] < 7);
	}
	body
	{
		...
	}

There. :)


T

-- 
You are only young once, but you can stay immature indefinitely. -- azephrahel