On 1/18/2015 12:46 AM, Brian Schott wrote:
> 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)

The other way around. Consider:

  class A(T) : C!(args), D!(more args), E!(lots of stuff) if (B)

the 'if' becomes significantly separated from A.

On 1/18/2015 12:16 AM, Daniel Murphy wrote:
> "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

Thanks for digging it up. I see I missed that one.

On Monday, 19 January 2015 at 02:24:00 UTC, Walter Bright wrote:
> On 1/18/2015 12:46 AM, Brian Schott wrote:
>> 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)
>
> The other way around. Consider:
>
>   class A(T) : C!(args), D!(more args), E!(lots of stuff) if (B)
>
> the 'if' becomes significantly separated from A.

That's exactly why I thing both should be allowed.

On 1/18/2015 7:07 PM, deadalnix wrote:
> On Monday, 19 January 2015 at 02:24:00 UTC, Walter Bright wrote:
>> On 1/18/2015 12:46 AM, Brian Schott wrote:
>>> 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)
>>
>> The other way around. Consider:
>>
>>   class A(T) : C!(args), D!(more args), E!(lots of stuff) if (B)
>>
>> the 'if' becomes significantly separated from A.
>
> That's exactly why I thing both should be allowed.

No. Constraints belong after the template declaration, not embedded in the template's implementation.

Furthermore, there's no useful purpose to enabling style wars and then requiring people to put one way in their coding standard document.

On Monday, 19 January 2015 at 03:57:14 UTC, Walter Bright wrote:
> No. Constraints belong after the template declaration, not embedded in the template's implementation.
>
> Furthermore, there's no useful purpose to enabling style wars and then requiring people to put one way in their coding standard document.

IMO style is the role of the formater. Prompting the programmer with "don't write this, write that instead" only crate reaction à la "If you know what I meant, why don't you compile that you asshole ?"

On 1/18/2015 8:23 PM, deadalnix wrote:
> IMO style is the role of the formater. Prompting the programmer with "don't
> write this, write that instead" only crate reaction à la "If you know what I
> meant, why don't you compile that you asshole ?"

Redundancy is built in to the language design on purpose. If there was no redundancy, any random sequence of bytes would be a valid program.

It's why statements end in ; even though it is not strictly necessary.

For an example from another industry, it's why double-entry bookkeeping was invented. Errors are reduced by introducing redundancy.

On 1/18/15 10:57 PM, Walter Bright wrote:
> On 1/18/2015 7:07 PM, deadalnix wrote:
>> On Monday, 19 January 2015 at 02:24:00 UTC, Walter Bright wrote:
>>> On 1/18/2015 12:46 AM, Brian Schott wrote:
>>>> 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)
>>>
>>> The other way around. Consider:
>>>
>>>   class A(T) : C!(args), D!(more args), E!(lots of stuff) if (B)
>>>
>>> the 'if' becomes significantly separated from A.
>>
>> That's exactly why I thing both should be allowed.
>
> No. Constraints belong after the template declaration, not embedded in
> the template's implementation.

I just want to point out then, the OP is asking for this same thing (template constraint to be allowed after the template declaration).

-Steve

On 1/17/15 3: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 ?


I kind of agree with you. Because this is short for:

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

I think it makes the most sense to put the constraint right after the template.

BUT:

1. I don't think there should be 2 ways to do this
2. The current requirement is not so horrible.

I would leave it alone.

-Steve

On Monday, 19 January 2015 at 10:49:52 UTC, Walter Bright wrote:
> On 1/18/2015 8:23 PM, deadalnix wrote:
>> IMO style is the role of the formater. Prompting the programmer with "don't
>> write this, write that instead" only crate reaction à la "If you know what I
>> meant, why don't you compile that you asshole ?"
>
> Redundancy is built in to the language design on purpose. If there was no redundancy, any random sequence of bytes would be a valid program.
>
> It's why statements end in ; even though it is not strictly necessary.
>
> For an example from another industry, it's why double-entry bookkeeping was invented. Errors are reduced by introducing redundancy.

Ideally, the redundancy is there to catch useful error, or it is just noise. I'm not sure what useful error we are catching here, as type system already to the check.