www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - post qualifier and template constraint limitation, is there a reason ?

reply "deadalnix" <deadalnix gmail.com> writes:
This is accepted :
auto fun(T)(T T) inout if(...) { ... }

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

Is there a reason ?
Jan 17 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 17 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
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 ?
Jan 17 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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" :-)
Jan 17 2015
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Jan 17 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Jan 17 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 17 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Jan 17 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 17 2015
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
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.
Jan 17 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 18 2015
parent reply "Brian Schott" <briancschott gmail.com> writes:
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)
Jan 18 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 18 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Jan 18 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 18 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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 ?"
Jan 18 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 19 2015
parent "deadalnix" <deadalnix gmail.com> writes:
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.
Jan 22 2015
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jan 19 2015
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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
Jan 18 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 18 2015
prev sibling next sibling parent zeljkog <zeljkog home.com> writes:
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.
Jan 17 2015
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
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(...) { ... }
=20
 This is not :
 auto fun(T)(T T) if(...) inout { ... }
=20
 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.
Jan 17 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Jan 17 2015
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
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=20
 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(...) { ... }
=20
 This is not :
 auto fun(T)(T T) if(...) inout { ... }
=20
 Is there a reason ?


 the first is easier to parse, and i it's looking better. the=20
 second is
 just unnecessary code in parser and will not be used in the=20
 wild to the
 extent that justifies increased complexity.


=20
 You obviously have data to back your point, both in term of=20
 readability, use in the wild and complexity added in the parser.=20
 Because if you don't, you have no point whatsoever and should=20
 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.
Jan 17 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Jan 17 2015
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
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=20
 Digitalmars-d wrote:

 sure i have. i made alot of patches to the parser, so i know=20
 how it
 is written. to make this work parser need to be changed not=20
 less than
 to accept ' ' before `pure`, `nothrow` and so on, and this=20
 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=20
 to add this in SDC's parser, so now what ? it tells nothing about=20
 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=20
 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.


=20
 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.
Jan 17 2015
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Jan 18 2015
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jan 19 2015