Walter Bright:
I believe we are talking past each other with no understanding.
The roadmap for the next three versions of Scala. Despite Scala
is used much more than D, they are willing to break library code
(shuffle around collections, turn mutable ones into immutable
ones), and change
On 07/25/2014 11:34 PM, Walter Bright wrote:
On 7/25/2014 2:53 AM, Jakob Ovrum wrote:
On Friday, 25 July 2014 at 09:39:23 UTC, Walter Bright wrote:
That can be special cased, too.
Seriously? Where does it end?
catch(MyTemplatedException!true) {
}
That one can't be special cased in the
On Monday, 28 July 2014 at 19:12:49 UTC, Timon Gehr wrote:
I'd suggest to just special case the general thing, or not add
any special cases at all.
catch(Type)
^~
I.e. use lookahead to determine whether something that looks
like a type follows a '(' token and is itself followed by a
On 07/28/2014 09:32 PM, Brian Schott wrote:
On Monday, 28 July 2014 at 19:12:49 UTC, Timon Gehr wrote:
I'd suggest to just special case the general thing, or not add any
special cases at all.
catch(Type)
^~
I.e. use lookahead to determine whether something that looks like a
type
On Monday, 28 July 2014 at 20:14:24 UTC, Timon Gehr wrote:
foreach(i;0..n){
// ...
}
(x).foo();
try{
// ...
}catch(Exception e){
return e;
}
(new Exception(hi)).msg.writeln;
I don't see how these are ambiguous.
On 07/28/2014 10:23 PM, Brian Schott wrote:
On Monday, 28 July 2014 at 20:14:24 UTC, Timon Gehr wrote:
foreach(i;0..n){
// ...
}
(x).foo();
try{
// ...
}catch(Exception e){
return e;
}
(new Exception(hi)).msg.writeln;
I don't see how these are ambiguous.
Both are ambiguous for
On Monday, 28 July 2014 at 20:51:55 UTC, Timon Gehr wrote:
Both are ambiguous for the same reason. They are ambiguous
because there exist delegate/function literals of the form
enum e={ return 2; }();
^
an expression
ForeachStatement:
...
On Saturday, 26 July 2014 at 01:24:31 UTC, Walter Bright wrote:
Ironically, today I'm being vehemently argued with for both
breaking code and not breaking code.
Are the arguments about intentional or unintentional breakages?
On Friday, 25 July 2014 at 23:12:33 UTC, Walter Bright wrote:
On 7/25/2014 3:56 PM, David Nadlinger wrote:
Let's just get rid of catch {} which encourages unsafe code
and be done with it.
We need to stop breaking code.
At SR Labs, we have no problems at all with that kind of
breakage: the
On Saturday, 26 July 2014 at 10:48:56 UTC, Paolo Invernizzi wrote:
On Friday, 25 July 2014 at 23:12:33 UTC, Walter Bright wrote:
On 7/25/2014 3:56 PM, David Nadlinger wrote:
Let's just get rid of catch {} which encourages unsafe code
and be done with it.
We need to stop breaking code.
At
On 7/21/2014 3:41 AM, Jakob Ovrum wrote:
On Thursday, 17 July 2014 at 21:03:08 UTC, Walter Bright wrote:
Did you see my response?
I suggested recognizing in the parser:
( Identifier )
as a special case, in addition to using Parser::isDeclaration().
I just want to point out that this
On Friday, 25 July 2014 at 09:39:23 UTC, Walter Bright wrote:
That can be special cased, too.
Seriously? Where does it end?
catch(MyTemplatedException!true) {
}
Parsing this as a proper type without a trailing identifier is a
nice feature that a lot of people use, unlike the ghastly catch
On 7/25/2014 2:53 AM, Jakob Ovrum wrote:
On Friday, 25 July 2014 at 09:39:23 UTC, Walter Bright wrote:
That can be special cased, too.
Seriously? Where does it end?
catch(MyTemplatedException!true) {
}
That one can't be special cased in the parser.
Parsing this as a proper type without
Walter Bright:
Because it breaks the least amount of code.
This is not a good idea. What about the future code that will be
buggy/wrong?
Bye,
bearophile
On Friday, 25 July 2014 at 21:34:22 UTC, Walter Bright wrote:
On 7/25/2014 2:53 AM, Jakob Ovrum wrote:
On Friday, 25 July 2014 at 09:39:23 UTC, Walter Bright wrote:
That can be special cased, too.
Seriously? Where does it end?
catch(MyTemplatedException!true) {
}
That one can't be special
On 7/25/2014 3:56 PM, David Nadlinger wrote:
Let's just get rid of catch {} which encourages unsafe code and be done with
it.
We need to stop breaking code.
Walter Bright:
We need to stop breaking code.
We also have a responsibility for the bad D code yet to be
written :-)
Bye,
bearophile
On Friday, 25 July 2014 at 23:12:33 UTC, Walter Bright wrote:
On 7/25/2014 3:56 PM, David Nadlinger wrote:
Let's just get rid of catch {} which encourages unsafe code
and be done with it.
We need to stop breaking code.
Either change breaks code. There's no evidence to support that
catch{}
On Saturday, 26 July 2014 at 00:10:00 UTC, Jakob Ovrum wrote:
On Friday, 25 July 2014 at 23:12:33 UTC, Walter Bright wrote:
On 7/25/2014 3:56 PM, David Nadlinger wrote:
Let's just get rid of catch {} which encourages unsafe code
and be done with it.
We need to stop breaking code.
Either
On Friday, 25 July 2014 at 23:12:33 UTC, Walter Bright wrote:
On 7/25/2014 3:56 PM, David Nadlinger wrote:
Let's just get rid of catch {} which encourages unsafe code
and be done with it.
We need to stop breaking code.
IMO breaking changes are justified if the changes fix a design
flaw in
On 7/25/2014 6:13 PM, Mike wrote:
IMO breaking changes are justified if the changes fix a design flaw in the
language or the changes break code that should have never been permitted.
Ironically, today I'm being vehemently argued with for both breaking code and
not breaking code.
On Saturday, 26 July 2014 at 01:24:31 UTC, Walter Bright wrote:
On 7/25/2014 6:13 PM, Mike wrote:
IMO breaking changes are justified if the changes fix a design
flaw in the
language or the changes break code that should have never been
permitted.
Ironically, today I'm being vehemently argued
On Saturday, 26 July 2014 at 01:24:31 UTC, Walter Bright wrote:
On 7/25/2014 6:13 PM, Mike wrote:
IMO breaking changes are justified if the changes fix a design
flaw in the
language or the changes break code that should have never been
permitted.
Ironically, today I'm being vehemently argued
On 7/25/2014 6:40 PM, Dicebot wrote:
tl; dr:
- breaking changes are good
- lack of any formal process for breaking changes is bad
- pretending that careful decisions for breakage make big difference is not
understanding the problem
I believe we are talking past each other with no
On Thursday, 17 July 2014 at 21:51:54 UTC, bearophile wrote:
Walter Bright:
The fear of breaking code should NOT freeze our brains in
terror. For each sigh of broken code could exist one thousand
sighs caused by broken designs that will keep causing troubles
forever.
+1
---
Paolo
On Thursday, 17 July 2014 at 21:03:08 UTC, Walter Bright wrote:
Did you see my response?
I suggested recognizing in the parser:
( Identifier )
as a special case, in addition to using Parser::isDeclaration().
I just want to point out that this special case is lacking, and
will inevitably
Walter Bright:
Unless a convincing counter argument emerges, yes.
Please Walter, list your convincing arguments to not fix the
situation.
Bye,
bearophile
On 7/17/2014 1:28 AM, bearophile wrote:
Walter Bright:
Unless a convincing counter argument emerges, yes.
Please Walter, list your convincing arguments to not fix the situation.
Breaks existing, working code for little gain. I suggested a fix that deals with
the issue and does not break
Deprecation of LastCatch doesn't break existing code either.
On 7/17/2014 2:40 AM, bearophile wrote:
Walter Bright:
Breaks existing, working code for little gain. I suggested a fix that deals
with the issue and does not break existing code.
This is not yet convincing. Let's talk about the Pokemon Exception Handling,
for when you just Gotta Catch 'Em
Walter Bright:
Breaks existing, working code for little gain. I suggested a
fix that deals with the issue and does not break existing code.
This is not yet convincing. Let's talk about the Pokemon
Exception Handling, for when you just Gotta Catch 'Em All :-) I
think the D/Python code that
On Thursday, 17 July 2014 at 09:57:37 UTC, Walter Bright wrote:
I.e. it's why, not why not make a breaking change.
Especially since it is apparently a commonly used coding
pattern, appearing 25 times in Phobos alone.
What?
The plan is to keep the syntax that is used in Phobos and get rid
of
On Thursday, 17 July 2014 at 09:57:37 UTC, Walter Bright wrote:
I.e. it's why, not why not make a breaking change.
Especially since it is apparently a commonly used coding
pattern, appearing 25 times in Phobos alone.
It is used 0 times in Phobos. In fact I have not seen it used for
a single
Dicebot wrote in message news:dikroykmroruujndl...@forum.dlang.org...
It is used 0 times in Phobos. In fact I have not seen it used for a single
time in any living project - guess because any sane person understands how
terrible of a misfeature it is.
I've used it, because I'm lazy.
On Thursday, 17 July 2014 at 10:38:46 UTC, Daniel Murphy wrote:
You will break some code if you disallow it.
An alternative was presented here: a warning and deprecation.
On 7/8/14, 2:31 PM, Brian Schott wrote:
http://wiki.dlang.org/DIP65
tldr: There are parser and specification bugs and I want to fix them. It
will break some poorly-written code, but I think I can automate the
upgrade process.
I vote we reject this DIP. It has clear appeal but there's also the
On Thursday, 17 July 2014 at 19:28:31 UTC, Andrei Alexandrescu
wrote:
On 7/8/14, 2:31 PM, Brian Schott wrote:
http://wiki.dlang.org/DIP65
tldr: There are parser and specification bugs and I want to
fix them. It
will break some poorly-written code, but I think I can
automate the
upgrade
On Thu, 17 Jul 2014 12:28:33 -0700, Andrei Alexandrescu wrote:
On 7/8/14, 2:31 PM, Brian Schott wrote:
http://wiki.dlang.org/DIP65
tldr: There are parser and specification bugs and I want to fix them.
It will break some poorly-written code, but I think I can automate the
upgrade process.
On 7/17/2014 1:44 PM, Justin Whear wrote:
On Thu, 17 Jul 2014 12:28:33 -0700, Andrei Alexandrescu wrote:
On 7/8/14, 2:31 PM, Brian Schott wrote:
http://wiki.dlang.org/DIP65
tldr: There are parser and specification bugs and I want to fix them.
It will break some poorly-written code, but I
On Thursday, 17 July 2014 at 21:03:08 UTC, Walter Bright wrote:
Did you see my response?
I suggested recognizing in the parser:
( Identifier )
as a special case, in addition to using
Parser::isDeclaration(). Gradually we can turn that special
case into a warning, then deprecation.
On 7/17/2014 2:03 PM, Walter Bright wrote:
Did you see my response?
I suggested recognizing in the parser:
( Identifier )
as a special case, in addition to using Parser::isDeclaration(). Gradually we
can turn that special case into a warning, then deprecation.
BTW, if doing the
Walter Bright wrote in message news:lq9dmc$2qeg$1...@digitalmars.com...
I suggested recognizing in the parser:
( Identifier )
as a special case, in addition to using Parser::isDeclaration(). Gradually
we can turn that special case into a warning, then deprecation.
Why on earth would
On 7/17/2014 2:17 PM, Daniel Murphy wrote:
Walter Bright wrote in message news:lq9dmc$2qeg$1...@digitalmars.com...
I suggested recognizing in the parser:
( Identifier )
as a special case, in addition to using Parser::isDeclaration(). Gradually we
can turn that special case into a
On Thu, 17 Jul 2014 14:03:06 -0700, Walter Bright wrote:
On 7/17/2014 1:44 PM, Justin Whear wrote:
On Thu, 17 Jul 2014 12:28:33 -0700, Andrei Alexandrescu wrote:
On 7/8/14, 2:31 PM, Brian Schott wrote:
http://wiki.dlang.org/DIP65
tldr: There are parser and specification bugs and I want to
On 7/17/2014 2:29 PM, Justin Whear wrote:
I suggested recognizing in the parser:
( Identifier )
as a special case, in addition to using Parser::isDeclaration().
Gradually we can turn that special case into a warning, then
deprecation.
Yes, this confuses me. You are suggesting that we
Walter Bright:
We need to STOP breaking existing code.
This is a small example case where I suggest to break
hypothetical existing code:
https://github.com/D-Programming-Language/phobos/pull/2077#issuecomment-49360265
The fear of breaking code should NOT freeze our brains in terror.
For
On Thu, 17 Jul 2014 14:43:59 -0700, Walter Bright wrote:
As I posted elsewhere, in the past there were many complaints about the
( Exception ) syntax and an expressed desire to deprecate it. I was
going along with that. But apparently those people who wanted it
deprecated are either silent in
On Thursday, 17 July 2014 at 21:51:54 UTC, bearophile wrote:
Walter Bright:
We need to STOP breaking existing code.
This is a small example case where I suggest to break
hypothetical existing code:
https://github.com/D-Programming-Language/phobos/pull/2077#issuecomment-49360265
The fear
On Thursday, 17 July 2014 at 21:44:02 UTC, Walter Bright wrote:
Writing such a tool is a major operation.
// I disagree.
module dfix;
import std.lexer;
import std.d.lexer;
import std.array;
import std.stdio;
void main(string[] args)
{
File input = File(args[1]);
File output
On Thursday, 17 July 2014 at 22:07:41 UTC, Brian Schott wrote:
On Thursday, 17 July 2014 at 21:44:02 UTC, Walter Bright wrote:
Writing such a tool is a major operation.
// I disagree.
Posted a bit too soon. Should look more like this..
case tok!catch:
Dicebot:
Your proposal there is much much worse than one to deprecate
`catch()` - it may result in silent change of behavior
Yes, sorry.
Bye,
bearophile
On 7/17/2014 3:07 PM, Brian Schott wrote:
On Thursday, 17 July 2014 at 21:44:02 UTC, Walter Bright wrote:
Writing such a tool is a major operation.
// I disagree.
[...]
I'm impressed. I withdraw that comment.
On 7/17/2014 3:17 PM, Walter Bright wrote:
On 7/17/2014 3:07 PM, Brian Schott wrote:
On Thursday, 17 July 2014 at 21:44:02 UTC, Walter Bright wrote:
Writing such a tool is a major operation.
// I disagree.
[...]
I'm impressed. I withdraw that comment.
BTW, it's not perfect because of
Walter Bright:
BTW, it's not perfect because of token string literals and
string mixins, but it's good enough.
In general the creation of a tool like Go fix
(http://golang.org/cmd/fix/ ) for D could change a little the
trade-offs regarding the tiny Phobos/D breaking changes.
Bye,
On Thu, Jul 17, 2014 at 11:39:56PM +, bearophile via Digitalmars-d wrote:
Walter Bright:
BTW, it's not perfect because of token string literals and string
mixins, but it's good enough.
In general the creation of a tool like Go fix
(http://golang.org/cmd/fix/ ) for D could change a
On 7/17/14, 3:01 PM, Dicebot wrote:
On Thursday, 17 July 2014 at 21:51:54 UTC, bearophile wrote:
Walter Bright:
We need to STOP breaking existing code.
This is a small example case where I suggest to break hypothetical
existing code:
On 7/17/14, 2:51 PM, bearophile wrote:
Walter Bright:
We need to STOP breaking existing code.
This is a small example case where I suggest to break hypothetical
existing code:
https://github.com/D-Programming-Language/phobos/pull/2077#issuecomment-49360265
The fear of breaking code should
On 7/17/14, 3:13 PM, Brian Schott wrote:
On Thursday, 17 July 2014 at 22:07:41 UTC, Brian Schott wrote:
On Thursday, 17 July 2014 at 21:44:02 UTC, Walter Bright wrote:
Writing such a tool is a major operation.
// I disagree.
Posted a bit too soon. Should look more like this..
On Friday, 18 July 2014 at 00:48:38 UTC, Andrei Alexandrescu
wrote:
That would be serious. What code would change behavior with
Walter's proposal? -- Andrei
That was an answer to bearophile, not Walter, false alarm ;)
On Friday, 18 July 2014 at 00:50:33 UTC, Andrei Alexandrescu
wrote:
Whatever comes of DIP65, it shouldn't influence our
determination to define such a tool. -- Andrei
I started with proposing this syntax change because it is the
easiest thing I can think of to fix automatically. Dfix should
On 7/17/14, 5:57 PM, Brian Schott wrote:
On Friday, 18 July 2014 at 00:50:33 UTC, Andrei Alexandrescu wrote:
Whatever comes of DIP65, it shouldn't influence our determination to
define such a tool. -- Andrei
I started with proposing this syntax change because it is the easiest
thing I can
On Wednesday, 9 July 2014 at 23:14:49 UTC, Brian Schott wrote:
If I'm understanding this correctly, you want to deprecate the
(somewhat popular) nameless exception syntax so that we can
keep the should be removed with prejudice catch-everything
syntax?
Is this the bottom line? Is DIP65
On 7/16/2014 4:04 PM, safety0ff wrote:
On Wednesday, 9 July 2014 at 23:14:49 UTC, Brian Schott wrote:
If I'm understanding this correctly, you want to deprecate the (somewhat
popular) nameless exception syntax so that we can keep the should be removed
with prejudice catch-everything syntax?
On Thursday, 17 July 2014 at 04:41:14 UTC, Walter Bright wrote:
On 7/16/2014 4:04 PM, safety0ff wrote:
On Wednesday, 9 July 2014 at 23:14:49 UTC, Brian Schott wrote:
If I'm understanding this correctly, you want to deprecate
the (somewhat
popular) nameless exception syntax so that we can
Walter Bright:
I suggest recognizing in the parser:
( Identifier )
as a special case, in addition to using
Parser::isDeclaration(). Gradually we can turn that special
case into a warning, then deprecation.
It's better to do the opposite, accept the common safe syntax
catch(Exception)
On Thursday, 10 July 2014 at 07:50:47 UTC, bearophile wrote:
Walter Bright:
I suggest recognizing in the parser:
( Identifier )
as a special case, in addition to using
Parser::isDeclaration(). Gradually we can turn that special
case into a warning, then deprecation.
It's better to do
On Wednesday, 9 July 2014 at 02:48:03 UTC, Walter Bright wrote:
On 7/8/2014 2:31 PM, Brian Schott wrote:
http://wiki.dlang.org/DIP65
tldr: There are parser and specification bugs and I want to
fix them. It will
break some poorly-written code, but I think I can automate the
upgrade process.
On 7/9/14, Brian Schott via Digitalmars-d digitalmars-d@puremagic.com wrote:
There is no ambiguity in the grammar. catch (A) { ... } is not
valid.
Give it a rest. If 'void foo(int, float)' is ok so should 'catch (E)'
be. We can change the spec if we have to, it's easier than breaking
code.
On Wednesday, 9 July 2014 at 12:20:43 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
Give it a rest. If 'void foo(int, float)' is ok so should
'catch (E)'
be. We can change the spec if we have to, it's easier than
breaking code.
Huh? Brian explicitly remarked earlier that
Implementing the
On Wednesday, 9 July 2014 at 12:20:43 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
On 7/9/14, Brian Schott via Digitalmars-d
digitalmars-d@puremagic.com wrote:
There is no ambiguity in the grammar. catch (A) { ... } is
not
valid.
Give it a rest. If 'void foo(int, float)' is ok so should
On 7/9/14, David Nadlinger via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Wednesday, 9 July 2014 at 12:20:43 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
Give it a rest. If 'void foo(int, float)' is ok so should
'catch (E)'
be. We can change the spec if we have to, it's easier than
On 7/9/2014 1:13 AM, Brian Schott wrote:
There is no ambiguity in the grammar. catch (A) { ... } is not valid. The spec
requires that you give the exception a name. A spec compliant D compiler MUST
parse your example code with the LastCatch rule. The fact that DMD does what it
does is a bug that
On Wednesday, 9 July 2014 at 20:11:46 UTC, Walter Bright wrote:
What the parser can do is do a lookahead on the ( ) to see if
it matches the 'BasicType Identifier' grammar.
Parser::isDeclaration() can be pressed into service to do that.
This should resolve the issue without breaking code.
On 7/9/2014 1:58 PM, Brian Schott wrote:
On Wednesday, 9 July 2014 at 20:11:46 UTC, Walter Bright wrote:
What the parser can do is do a lookahead on the ( ) to see if it matches the
'BasicType Identifier' grammar. Parser::isDeclaration() can be pressed into
service to do that. This should
On Wednesday, 9 July 2014 at 23:01:13 UTC, Walter Bright wrote:
Interesting. Those are invalid D code, but obviously the
compiler is accepting it.
I suggest recognizing in the parser:
( Identifier )
as a special case, in addition to using
Parser::isDeclaration(). Gradually we can turn
On 7/8/2014 2:31 PM, Brian Schott wrote:
http://wiki.dlang.org/DIP65
tldr: There are parser and specification bugs and I want to fix them. It will
break some poorly-written code, but I think I can automate the upgrade process.
I don't want to break existing code. The grammar ambiguity issue
76 matches
Mail list logo
