This is accepted :
auto fun(T)(T T) inout if(...) { ... }

This is not :
auto fun(T)(T T) if(...) inout { ... }

Is there a reason ?

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.

On 17.01.15 09:33, 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 think it improves readability. A little :)
Often user don't care to read if-part.

On Sat, 17 Jan 2015 08:33:49 +0000
deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> 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 ?
the first is easier to parse, and i it's looking better. the second is just unnecessary code in parser and will not be used in the wild to the extent that justifies increased complexity.

On Saturday, 17 January 2015 at 16:02:16 UTC, ketmar via Digitalmars-d wrote:
> On Sat, 17 Jan 2015 08:33:49 +0000
> deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> 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 ?
> the first is easier to parse, and i it's looking better. the second is
> just unnecessary code in parser and will not be used in the wild to the
> extent that justifies increased complexity.

You obviously have data to back your point, both in term of readability, use in the wild and complexity added in the parser. Because if you don't, you have no point whatsoever and should probably not be posting.

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 ?

On Sat, 17 Jan 2015 16:55:31 +0000
deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Saturday, 17 January 2015 at 16:02:16 UTC, ketmar via Digitalmars-d wrote:
> > On Sat, 17 Jan 2015 08:33:49 +0000
> > deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> 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 ?
> > the first is easier to parse, and i it's looking better. the
> > second is
> > just unnecessary code in parser and will not be used in the
> > wild to the
> > extent that justifies increased complexity.
> 
> You obviously have data to back your point, both in term of readability, use in the wild and complexity added in the parser. Because if you don't, you have no point whatsoever and should probably not be posting.
sure i have. i made alot of patches to the parser, so i know how it is written. to make this work parser need to be changed not less than to accept '@' before `pure`, `nothrow` and so on, and this change was rejected due to added complexity for supporting it by devteam.

as for "will not be used" -- you can use google to count requests for this feature. the numbers will show you how much people miss it.

i have no habit of writing tales from the faery world, you know.

On Saturday, 17 January 2015 at 17:08:12 UTC, ketmar via Digitalmars-d wrote:
> sure i have. i made alot of patches to the parser, so i know how it
> is written. to make this work parser need to be changed not less than
> to accept '@' before `pure`, `nothrow` and so on, and this change was
> rejected due to added complexity for supporting it by devteam.
>

I'm sorry but this is not a good reason. It would be failry easy to add this in SDC's parser, so now what ? it tells nothing about the feature and everything about DMD's parser.

> as for "will not be used" -- you can use google to count requests for
> this feature. the numbers will show you how much people miss it.
>
> i have no habit of writing tales from the faery world, you know.

Absence of information is not information.

On Sat, 17 Jan 2015 17:34:21 +0000
deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Saturday, 17 January 2015 at 17:08:12 UTC, ketmar via Digitalmars-d wrote:
> > sure i have. i made alot of patches to the parser, so i know
> > how it
> > is written. to make this work parser need to be changed not
> > less than
> > to accept '@' before `pure`, `nothrow` and so on, and this
> > change was
> > rejected due to added complexity for supporting it by devteam.
> >
> I'm sorry but this is not a good reason. It would be failry easy to add this in SDC's parser, so now what ? it tells nothing about the feature and everything about DMD's parser.
this was one of the good reasons to reject `@pure` syntax, so i can't see why it's not a good reason to reject OP's syntax.

> > as for "will not be used" -- you can use google to count
> > requests for
> > this feature. the numbers will show you how much people miss it.
> >
> > i have no habit of writing tales from the faery world, you know.
> 
> Absence of information is not information.
i don't think that you are right here. but i'm not in the right mood to argue.

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" :-)