Walter:
Here you are essentially asking for a more global view of the D design, to see
if we are using too much plastic surgery. To have such global view we need to
look at many unrelated things. So sorry if this looks like a lot of meat on the
fire, there is no other way.
We've already put
And there are few more special cases where I'd like to see
changes/improvements on (there are other improvements that I'd like to see,
but they aren't special cases):
3878 Arguments and attributes with the same name
4407 Catch wrong argument-attribute assignments in methods
5187
Am 26.08.2011, 11:32 Uhr, schrieb bearophile bearophileh...@lycos.com:
There is one more special case that we plan to disallow, that's not in
DMD yet:
5409 Disallow (!x y)
http://d.puremagic.com/issues/show_bug.cgi?id=5409
Is (!x y) an issue or is it rather people omitting spaces in
Marco Leise:
Is (!x y) an issue or is it rather people omitting spaces in their code
!xy ?
This topic was already discussed in past, in two threads, this one of them:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=135741
The Coccinelle tool has found a
Am 26.08.2011, 13:10 Uhr, schrieb bearophile bearophileh...@lycos.com:
Marco Leise:
Is (!x y) an issue or is it rather people omitting spaces in their
code
!xy ?
This topic was already discussed in past, in two threads, this one of
them:
On 8/25/11 9:13 PM, Walter Bright wrote:
On 8/25/2011 6:30 PM, Andrei Alexandrescu wrote:
On 8/25/11 6:10 PM, Walter Bright wrote:
On 8/25/2011 6:04 PM, Nick Sabalausky wrote:
Oh god no, don't ban that. I *like* to do that sort of thing:
Unusual, but legitimate. I think I'll shelve the
On Fri, 26 Aug 2011 11:03:21 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
It's a legitimate concern, and there's no right response to it. My point
is that the argument is weak and caving to it would be a mistake. In
essence Nick claims he can't be bothered to change:
On 8/26/11 8:48 AM, Steven Schveighoffer wrote:
On Fri, 26 Aug 2011 11:03:21 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
It's a legitimate concern, and there's no right response to it. My
point is that the argument is weak and caving to it would be a
mistake. In essence
I've used this a few times:
foreach (dir; dirs)
foreach (string file; dirEntries(dir, SpanMode.shallow))
{
if (file.isFile)
// do something..
}
And I only use this in short loops like this. It's more compact, I
dislike having to create too much indentation.
I don't see what banning
Andrej Mitrovic:
I don't see what banning this buys us.
That's not banned.
Bye,
bearophile
Marco Leise:
Does your enhancement include other operators like '' or is it
practically just for the 'check if flag is disabled' case?
My enhancement request regards just a narrow case.
(But the actual implementation of it may add some other related cases, I don't
know).
Bye,
bearophile
we might as well get rid of the semicolon as well.
You can have my semicolons when you pry them from my cold, dead hands.
Andrej Mitrovic:
Ok, I thought this was included.
It wasn't included in my original enhancement request. But now I don't exactly
know what situations Andrei wants to disallow.
Bye,
bearophile
On 8/26/11, Adam Ruppe destructiona...@gmail.com wrote:
we might as well get rid of the semicolon as well.
You can have my semicolons when you pry them from my cold, dead hands.
I'd kill them (the semicolons, not your hands :p) in places they're
not needed anymore. And we already have that in
On 26.08.2011 17:03, Andrei Alexandrescu wrote:
On 8/25/11 9:13 PM, Walter Bright wrote:
But I worry that we might wind up tarting up the language with too many
a boatload of them, to the point where it becomes a confusing mass. At
what point should Meg Ryan stop with the plastic surgery? :-)
On 2011/08/27 1:52, Andrej Mitrovic wrote:
Of course they're still needed in other places, but to be
honest I'm tired of found foo, expected bla errors due to missing
semicolons.
You can have both semi-colons and nice error messages if you put some
effort into the parser. Clang manages this
Cool stuff! DMD is almost there but it reports the line number of
whatever comes next, even if there was only whitespace, e.g.:
void main()
{
int foo = 2
} - error line here instead of above
Steven Schveighoffer schvei...@yahoo.com wrote:
Hm... the only problem I see with simply disallowing if(a) if(b) is this:
if(a)
while(condition)
if(b)
statement;
else // oops! this goes with if(b)
statement;
Or would this be disallowed as well? This could not be
kennytm:
I've created a patch* for dangling else checking.
I have not yet compiled and tried your code, but from what I see all the design
decisions you have taken are good, including the error message (I think it
doesn't need to contain dangling else because that's a different thing), the
Walter Bright newshou...@digitalmars.com wrote in message
news:j313kp$1fc1$1...@digitalmars.com...
On 8/19/2011 8:12 AM, Andrei Alexandrescu wrote:
One thing I'd subjectively like is to require braces on both branches of
if/else
if at least one has braces.
It's rather simple to just
On 8/25/2011 6:04 PM, Nick Sabalausky wrote:
Oh god no, don't ban that. I *like* to do that sort of thing:
Unusual, but legitimate. I think I'll shelve the idea.
Walter:
Nick Sabalausky wrote:
Oh god no, don't ban that. I *like* to do that sort of thing:
Unusual, but legitimate. I think I'll shelve the idea.
This is the code by Nick Sabalausky:
if(useThisFeature)
foreach(x; 0..100)
foreach(y; 0..100)
if(blah blah long thing)
if(simple
On 8/25/11 6:10 PM, Walter Bright wrote:
On 8/25/2011 6:04 PM, Nick Sabalausky wrote:
Oh god no, don't ban that. I *like* to do that sort of thing:
Unusual, but legitimate. I think I'll shelve the idea.
It would be great to reconsider. The counter-argument is very weak.
Andrei
On 8/25/2011 6:30 PM, Andrei Alexandrescu wrote:
On 8/25/11 6:10 PM, Walter Bright wrote:
On 8/25/2011 6:04 PM, Nick Sabalausky wrote:
Oh god no, don't ban that. I *like* to do that sort of thing:
Unusual, but legitimate. I think I'll shelve the idea.
It would be great to reconsider. The
Walter Bright newshou...@digitalmars.com wrote:
We've already put a number of special cases in the grammar to ward off bugs.
But I worry that we might wind up tarting up the language with too many a
boatload of them, to the point where it becomes a confusing mass. At what
point should Meg
Walter Bright newshou...@digitalmars.com wrote:
On 8/19/2011 8:12 AM, Andrei Alexandrescu wrote:
One thing I'd subjectively like is to require braces on both branches of
if/else
if at least one has braces.
It's rather simple to just disallow the form:
if (a) if (b) statement
On 8/24/2011 1:09 AM, kennytm wrote:
Not sure if it's a big enough problem, but what about dangling else of this
form?
if (a.length 0)
foreach (i, ref e; a)
if (i 0)
e += a[i-1];
else // oops
throw new Exception(empty array);
On 8/23/2011 3:32 PM, Andrei Alexandrescu wrote:
Yah, disallowing complete and nested if/else pairs would be an annoyance (I'm
not sure how big). Otherwise, Walter's idea sounds good to me. Walter, would you
be okay with accepting if-if-else-else (at any depth) as a correct case and
otherwise
On 08/24/2011 06:22 PM, Walter Bright wrote:
On 8/24/2011 1:09 AM, kennytm wrote:
Not sure if it's a big enough problem, but what about dangling else of
this
form?
if (a.length 0)
foreach (i, ref e; a)
if (i 0)
e += a[i-1];
else // oops
throw new Exception(empty array);
That wouldn't be
On 8/19/2011 8:12 AM, Andrei Alexandrescu wrote:
One thing I'd subjectively like is to require braces on both branches of if/else
if at least one has braces.
It's rather simple to just disallow the form:
if (a) if (b) statement
^ error: use if(ab) or if(a){if(b)statement}
and
On 08/23/2011 10:46 PM, Walter Bright wrote:
On 8/19/2011 8:12 AM, Andrei Alexandrescu wrote:
One thing I'd subjectively like is to require braces on both branches
of if/else
if at least one has braces.
It's rather simple to just disallow the form:
if (a) if (b) statement
^ error: use if(ab)
On 8/23/11 2:31 PM, Timon Gehr wrote:
On 08/23/2011 10:46 PM, Walter Bright wrote:
On 8/19/2011 8:12 AM, Andrei Alexandrescu wrote:
One thing I'd subjectively like is to require braces on both branches
of if/else
if at least one has braces.
It's rather simple to just disallow the form:
if
On Sun, 21 Aug 2011 20:32:05 +0200, Jacob Carlborg wrote:
Yes, the else is for the second if-statement, not the first one. That's
why I always use braces when I have nested if-statements, at least for
the outer if-statement.
That rule is too complicated for me. :) My version is I always use
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:j2luh6$23bb$1...@digitalmars.com...
One thing I'd subjectively like is to require braces on both branches of
if/else if at least one has braces.
Yuck! I'd really hate that.
Nick Sabalausky:
Yuck! I'd really hate that.
Recently I have converted this Python code:
def foo(sol):
global best
if is_solution(sol[-1]):
if best or len(sol) len(best):
best = list(sol)
else:
for next in alternatives(sol[-1]):
if next not
On 2011-08-21 20:02, bearophile wrote:
Nick Sabalausky:
Yuck! I'd really hate that.
Recently I have converted this Python code:
def foo(sol):
global best
if is_solution(sol[-1]):
if best or len(sol) len(best):
best = list(sol)
else:
for next
On Sunday, August 21, 2011 12:47:22 Nick Sabalausky wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:j2luh6$23bb$1...@digitalmars.com...
One thing I'd subjectively like is to require braces on both branches of
if/else if at least one has braces.
Yuck! I'd
bearophile bearophileh...@lycos.com wrote in message
news:j2rh7g$2tfq$1...@digitalmars.com...
To this innocent-looking D code, do you see the problem?
void foo(Pair[] sol) {
if (isSolution(sol[$-1]))
if (!best.length || sol.length best.length)
best = sol.dup;
else
On 8/21/11 4:02 PM, Nick Sabalausky wrote:
bearophilebearophileh...@lycos.com wrote in message
news:j2rh7g$2tfq$1...@digitalmars.com...
To this innocent-looking D code, do you see the problem?
void foo(Pair[] sol) {
if (isSolution(sol[$-1]))
if (!best.length || sol.length
On 08/21/2011 11:02 PM, Nick Sabalausky wrote:
bearophilebearophileh...@lycos.com wrote in message
news:j2rh7g$2tfq$1...@digitalmars.com...
To this innocent-looking D code, do you see the problem?
void foo(Pair[] sol) {
if (isSolution(sol[$-1]))
if (!best.length || sol.length
Andrei Alexandrescu:
Yah, it's pretty neat, and very much in the spirit of D. I'd missed it.
Thank you Andrei. This problem is know as Dangling else problem. When a bug
receives a name, you know it's common enough.
This is one of the about one dozen of tiny/small breaking changes I'd like for
On Sunday, August 21, 2011 20:36:55 bearophile wrote:
Andrei Alexandrescu:
Yah, it's pretty neat, and very much in the spirit of D. I'd missed it.
Thank you Andrei. This problem is know as Dangling else problem. When a
bug receives a name, you know it's common enough.
This is one of the
Jonathan M Davis:
Except that it's not a bug. It's an issue that crops up in grammars for
programming languages.
Right, I have just seen I was wrong :-)
There is classic solution to the problem which D
follows. So, there is no ambiguity, and there is no bug. It's very much by
design.
, but compared with Java, D also allow try, catch and finally
statements to have optional braces.
What about extending this to allow optional braces everywhere, where the
braces contain a single expression? I'm thinking this will be most
useful for functions/methods, templates and delegates. Specially
expression. In D this is true
as well, but compared with Java, D also allow try, catch and finally
statements to have optional braces.
What about extending this to allow optional braces everywhere, where the
braces contain a single expression? I'm thinking this will be most
useful for functions
Am 19.08.2011, 14:16 Uhr, schrieb Timon Gehr timon.g...@gmx.ch:
I think this makes code harder to read for no obvious benefit.
I don't think this is any better than
class Foo{
private int a_;
int a(){return a_;}
int a(int a){return a_ = a;}
}
+1
Optional braces should
don't think this is any better than
class Foo{
private int a_;
int a(){return a_;}
int a(int a){return a_ = a;}
}
+1
Optional braces should be limited to statements.
= a;}
}
+1
Optional braces should be limited to statements.
I agree. Besides, a minor problem is that 'if' statements may be mistaken
as template conditions:
void f1(T)(T x) if (isFoo!T) { x ++; }
void f2(T)(T x) { if (isFoo!T) { x ++; } }
expression. In D this is true
as well, but compared with Java, D also allow try, catch and finally
statements to have optional braces.
What about extending this to allow optional braces everywhere, where the
braces contain a single expression? I'm thinking this will be most
useful for functions/methods
like if,
while, for and so on, containing only one expression. In D this is true
as well, but compared with Java, D also allow try, catch and finally
statements to have optional braces.
What about extending this to allow optional braces everywhere, where the
braces contain a single expression? I'm
if,
while, for and so on, containing only one expression. In D this is true
as well, but compared with Java, D also allow try, catch and finally
statements to have optional braces.
What about extending this to allow optional braces everywhere, where the
braces contain a single expression? I'm
;}
int a(int a){return a_ = a;}
}
+1
Optional braces should be limited to statements.
I agree. Besides, a minor problem is that 'if' statements may be mistaken
as template conditions:
void f1(T)(T x) if (isFoo!T) { x ++; }
void f2(T)(T x) { if (isFoo!T) { x ++; } }
Oh, never
52 matches
Mail list logo
