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
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
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 cl
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 purpo
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
standar
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
mistak
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 requ
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 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 dfi
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
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
cla
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 whe
"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 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
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 belie
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 t
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 pr
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
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 tim
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 k
On Sat, 17 Jan 2015 17:34:21 +
deadalnix via Digitalmars-d 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
>
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
On Sat, 17 Jan 2015 16:55:31 +
deadalnix via Digitalmars-d wrote:
> On Saturday, 17 January 2015 at 16:02:16 UTC, ketmar via
> Digitalmars-d wrote:
> > On Sat, 17 Jan 2015 08:33:49 +
> > deadalnix via Digitalmars-d wrote:
> >
> >> This is accepted :
> >> auto fun(T)(T T) inout if(...) {
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 ma
On Saturday, 17 January 2015 at 16:02:16 UTC, ketmar via
Digitalmars-d wrote:
On Sat, 17 Jan 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 ?
the first is
On Sat, 17 Jan 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 ?
the first is easier to parse, and i it's looking better. the second is
just unne
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 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.
This is accepted :
auto fun(T)(T T) inout if(...) { ... }
This is not :
auto fun(T)(T T) if(...) inout { ... }
Is there a reason ?
29 matches
Mail list logo
