Walter Bright:

> Sure, but you'll need a rationale that is better than "why not" :-)

Often in a language it's a good idea to have only one way to do something. To have two places to put those attributes generates the question: where do you want to put them? And it's a question that wastes time. In Python you don't have "wars" regarding where to put the { } because there is just one way to format code and indentations... and it's a good way.

Bye,
bearophile

On Saturday, 17 January 2015 at 21:15:53 UTC, Walter Bright wrote:
> On 1/17/2015 8:56 AM, deadalnix wrote:
>> On Saturday, 17 January 2015 at 10:05:29 UTC, Walter Bright wrote:
>>> On 1/17/2015 12:33 AM, deadalnix wrote:
>>>> This is accepted :
>>>> auto fun(T)(T T) inout if(...) { ... }
>>>>
>>>> This is not :
>>>> auto fun(T)(T T) if(...) inout { ... }
>>>>
>>>> Is there a reason ?
>>>
>>> There was no known reason to.
>>
>> Is that possible to make it work then ? Should I open a bug ?
>
> Sure, but you'll need a rationale that is better than "why not" :-)

Because I can never remember which one it is and run into the wrong case 50% of the time. I'd assume that I'm not the only one, but, as I have done for ages, do not consider this as an issue big enough to complain. This is the kind of thing that drain you productivity minute by minute.

Kind of like

class C(T) : B if(...) {} vs class C(T) if(...) : B {}

That Brian mentioned in his DConf talk. It is just another instance of the same problem. Only one used to be accepted, but now both are valid. It looks like to me like another instance of the same problem.

On 1/17/2015 4:06 PM, deadalnix wrote:
> Because I can never remember which one it is and run into the wrong case 50% of
> the time. I'd assume that I'm not the only one, but, as I have done for ages, do
> not consider this as an issue big enough to complain. This is the kind of thing
> that drain you productivity minute by minute.
>
> Kind of like
>
> class C(T) : B if(...) {} vs class C(T) if(...) : B {}
>
> That Brian mentioned in his DConf talk. It is just another instance of the same
> problem. Only one used to be accepted, but now both are valid. It looks like to
> me like another instance of the same problem.

On the other hand, I think having only one way to do it is better for consistency and stylistic reasons.

For example, I never liked that:

    int short unsigned

is valid in C. I don't believe it adds value.

On Sunday, 18 January 2015 at 00:19:47 UTC, Walter Bright wrote:
> On the other hand, I think having only one way to do it is better for consistency and stylistic reasons.
>
> For example, I never liked that:
>
>     int short unsigned
>
> is valid in C. I don't believe it adds value.

You are basically telling me that consistency matter. If so, we either rollback the class case, or go forward on that one.

Considering how many time I ran in both of them, we are better off without.

On 1/17/2015 5:33 PM, deadalnix wrote:
> On Sunday, 18 January 2015 at 00:19:47 UTC, Walter Bright wrote:
>> On the other hand, I think having only one way to do it is better for
>> consistency and stylistic reasons.
>>
>> For example, I never liked that:
>>
>>     int short unsigned
>>
>> is valid in C. I don't believe it adds value.
>
> You are basically telling me that consistency matter. If so, we either rollback
> the class case, or go forward on that one.

I don't really know where the class change came from :-(


> Considering how many time I ran in both of them, we are better off without.

On Sunday, 18 January 2015 at 07:47:04 UTC, Walter Bright wrote:
> On 1/17/2015 5:33 PM, deadalnix wrote:
>> You are basically telling me that consistency matter. If so, we either rollback
>> the class case, or go forward on that one.
>
> I don't really know where the class change came from :-(

I could write a dfix rule to clean up class declarations. I prefer consistency because it makes creating tools for D easier and because I don't have to explain to people why there's more than one right way to do exactly the same thing.

"Walter Bright"  wrote in message news:m9fodo$18lu$1@digitalmars.com... 

> I don't really know where the class change came from :-(

https://github.com/D-Programming-Language/dmd/pull/1227

On 1/17/2015 11:52 PM, Brian Schott wrote:
> On Sunday, 18 January 2015 at 07:47:04 UTC, Walter Bright wrote:
>> On 1/17/2015 5:33 PM, deadalnix wrote:
>>> You are basically telling me that consistency matter. If so, we either rollback
>>> the class case, or go forward on that one.
>>
>> I don't really know where the class change came from :-(
>
> I could write a dfix rule to clean up class declarations. I prefer consistency
> because it makes creating tools for D easier and because I don't have to explain
> to people why there's more than one right way to do exactly the same thing.

Sounds like a good idea. If I wasn't clear, I think that class change was a mistake.

On Sunday, 18 January 2015 at 08:40:19 UTC, Walter Bright wrote:
> Sounds like a good idea. If I wasn't clear, I think that class change was a mistake.

Now that I see from that pull request that the ugly syntax was the original, I'm not so sure. The dfix feature I'm planning is to convert

class A if (B) : C

to

class A : C if (B)

On Saturday, January 17, 2015 08:33:49 deadalnix via Digitalmars-d wrote:
> This is accepted :
> auto fun(T)(T T) inout if(...) { ... }
>
> This is not :
> auto fun(T)(T T) if(...) inout { ... }
>
> Is there a reason ?

Well, inout is part of the signature. It's debatable as to whether the template constraint is, particularly when you consider that what you're really dealing with is

template fun(T)
    if(...)
{
    auto fun(T t) inout {...}
}

just with a shorter syntax. And I'd guess that you have trouble remembering whether the inout goes primarily due to your coding style. I don't think that I _ever_ put the template constraint on the same line as the signature, so I've never had any trouble remembering where the function attributes go in comparison to the template constraint, and it would never have occurred to me that anyone would have a problem with that.

But in general, I think that having multiple ways to do the same thing needs a good reason, especially when it means adding a new way to do something, and I think that the fact that the template constraint isn't really part of the function signature is a good reason not to allow the function attributes after it.

- Jonathan M Davis