Leandro Lucarella wrote:
That's completely FALSE. You might need some bugfixes! That
view of if you want to be up to date you have to be
willing to update a lot of code is really hurting D's
stability.
Evolution was never pain-free. The idea that D can thrive without
adapting to it's
On Friday, 24 May 2013 at 13:54:21 UTC, Dicebot wrote:
There is an option to prohibit initializers for struct member
declarations at all and allow CTFE-able default constructors
instead, but that would have been a major change.
I don't see a reason why we couldn't have both ways (1. member
On Monday, 27 May 2013 at 07:32:15 UTC, TommiT wrote:
I don't see a reason why we couldn't have both ways (1. member
initializers and 2. CTFE-able default constructor) for defining
the init state of structs. Probably the sensible thing would be
to make all member initializers illegal iff a
Dicebot, el 23 de May a las 16:42 me escribiste:
something I may have actually used in real code writing a low-level
networking library:
struct Packet
{
immutable etherType = 0x0800; // IPv4 by default;
// ...
this(bool IPv6)
{
if
Andrei Alexandrescu, el 23 de May a las 12:57 me escribiste:
On 5/23/13 9:12 AM, Don wrote:
No, it's not, it's a fix plus a new misfeature.
Don, you're wrong. The feature is sensible. The problem with it is
that it changes semantics of existing code.
Is not sensible for code review. For me
On Monday, 27 May 2013 at 17:08:19 UTC, Leandro Lucarella wrote:
You can achieve the same with:
if (!IPv6)
etherType = 0x0800;
else
...
There is no need to double-initialize a immutable value.
As I have already
Steven Schveighoffer, el 23 de May a las 23:53 me escribiste:
On Thu, 23 May 2013 23:38:32 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:
This is one change where ALL code broken by this change
is fixable with a simple solution, and
On Saturday, 25 May 2013 at 21:07:26 UTC, Walter Bright wrote:
Pull request to do this:
https://github.com/D-Programming-Language/dmd/pull/2076
So finally, what is the sate of things ?
On 5/26/2013 9:31 AM, deadalnix wrote:
On Saturday, 25 May 2013 at 21:07:26 UTC, Walter Bright wrote:
Pull request to do this: https://github.com/D-Programming-Language/dmd/pull/2076
So finally, what is the sate of things ?
Beta 7!
http://ftp.digitalmars.com/dmd2beta.zip
Remaining
On Saturday, 25 May 2013 at 05:32:28 UTC, deadalnix wrote:
They define a default value for the field. The constructor can
override it. It is expected that a constructor is able to
construct an object.
Yes, I know. Actually, I have been saying it earlier in this
topic. So what? :)
On Sunday, 26 May 2013 at 18:52:11 UTC, Walter Bright wrote:
On 5/26/2013 9:31 AM, deadalnix wrote:
On Saturday, 25 May 2013 at 21:07:26 UTC, Walter Bright wrote:
Pull request to do this:
https://github.com/D-Programming-Language/dmd/pull/2076
So finally, what is the sate of things ?
On 5/26/2013 8:05 PM, deadalnix wrote:
On Sunday, 26 May 2013 at 18:52:11 UTC, Walter Bright wrote:
On 5/26/2013 9:31 AM, deadalnix wrote:
On Saturday, 25 May 2013 at 21:07:26 UTC, Walter Bright wrote:
Pull request to do this:
https://github.com/D-Programming-Language/dmd/pull/2076
So
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This
one is pretty much good to go, unless something disastrous
crops up.
http://ftp.digitalmars.com/dmd2beta.zip
Remaining regressions:
On 2013-05-24 02:01, Walter Bright wrote:
Don has an excellent point. His case is bolstered by this causing Tango2
to fail to compile with error messages that have no obvious relationship
with this change.
Worse, as Don points out, this can result in silent breakage. Not
everyone writes code
On 23 May 2013 22:46, Walter Bright newshou...@digitalmars.com wrote:
On 5/23/2013 4:07 AM, Iain Buclaw wrote:
On 21 May 2013 21:36, Walter Bright newshou...@digitalmars.com wrote:
Join the dmd beta mailing list to keep up with the betas. This one is
pretty
much good to go, unless
On Thursday, 23 May 2013 at 22:25:18 UTC, Andrej Mitrovic wrote:
On 5/23/13, Vladimir Panteleev vladi...@thecybershadow.net
wrote:
2) it doesn't know which file is the main
program file (the file which must be present for the test
script
to succeed), if there is one.
Does
On Thursday, 23 May 2013 at 16:01:56 UTC, Don wrote:
That's better, but it's still not a convincing example.
I don't see why you cannot remove the intializer, and write:
this(bool IPv6)
{
if (!IPv6)
etherType = 0x0800;
else
etherType = 0x86DD;
...
}
Because then you
I like it. A lot, probably.
When semantics of something does change it makes a lot sense to
decouple deprecation of old behavior and introduction of new. I
may even say it is worth using as a default approach for a
semantics change in similar cases ;)
On Friday, 24 May 2013 at 00:01:20 UTC,
On Thu, 23 May 2013 19:52:14 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/23/13 2:08 PM, Marco Leise wrote:
Am Thu, 23 May 2013 13:06:44 -0400
schrieb Andrei Alexandrescuseewebsiteforem...@erdani.org:
TDPL 8.4 discusses a raw/cooked model of construction. The same
On 05/24/13 02:33, Steven Schveighoffer wrote:
On Thu, 23 May 2013 19:03:25 -0400, Artur Skawina art.08...@gmail.com wrote:
On 05/23/13 23:06, Steven Schveighoffer wrote:
compiles:
struct S
{
const int x;
this(int n)
{
x = n;
}
}
It's the 'const int x = 42;' case
On 5/24/13 5:09 AM, Regan Heath wrote:
On Thu, 23 May 2013 19:52:14 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/23/13 2:08 PM, Marco Leise wrote:
Am Thu, 23 May 2013 13:06:44 -0400
schrieb Andrei Alexandrescuseewebsiteforem...@erdani.org:
TDPL 8.4 discusses a
On Friday, 24 May 2013 at 11:57:53 UTC, Don wrote:
On Friday, 24 May 2013 at 10:55:09 UTC, Artur Skawina wrote:
Hence, you are arguing for a change in behavior. And the
arguments for that
are extremely weak. The goal should be to allow const
initialization to happen
exactly once.
I agree.
On Friday, 24 May 2013 at 11:57:53 UTC, Don wrote:
...
I have finally understood your point about default initializer vs
changing T.init :) It was not that easy because there are no
similar terms in other languages. Anyway, it does make sense.
Somehow separating concept of compile-time
On Thursday, 23 May 2013 at 16:44:03 UTC, deadalnix wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This
one is pretty much good to go, unless something disastrous
crops up.
On Friday, 24 May 2013 at 13:06:03 UTC, deadalnix wrote:
Solved, but now I fail on :
Error: template std.utf.decodeFront does not match any function
template declaration. Candidates are:
... // Many candidates.
So I fixed it, now I have another regression (or a new feature) :
Foo is not a
On Fri, 24 May 2013 07:57:51 -0400, Don turnyourkidsintoc...@nospam.com
wrote:
On Friday, 24 May 2013 at 10:55:09 UTC, Artur Skawina wrote:
On 05/24/13 02:33, Steven Schveighoffer wrote:
On Thu, 23 May 2013 19:03:25 -0400, Artur Skawina
art.08...@gmail.com wrote:
On 05/23/13 23:06,
On Fri, 24 May 2013 09:54:20 -0400, Dicebot m.stras...@gmail.com wrote:
On Friday, 24 May 2013 at 13:46:49 UTC, Steven Schveighoffer wrote:
This was ALWAYS the case.
struct S
{
int x = 5; // sets S.init.x to 5
}
As far as I understand Don, this behavior should be considered
misleading
On Friday, 24 May 2013 at 13:58:32 UTC, Steven Schveighoffer
wrote:
Being able to dictate the .init data is very powerful and
useful. You can't remove that feature.
Sure, I completely agree, thus the idea adding of CTFE-able
constructor which will become the T.init for structs.
But the
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This
one is pretty much good to go, unless something disastrous
crops up.
http://ftp.digitalmars.com/dmd2beta.zip
Remaining regressions:
On Friday, 24 May 2013 at 14:04:33 UTC, Dicebot wrote:
On Friday, 24 May 2013 at 13:58:32 UTC, Steven Schveighoffer
wrote:
Being able to dictate the .init data is very powerful and
useful. You can't remove that feature.
Sure, I completely agree, thus the idea adding of CTFE-able
constructor
On 2013-05-21 22:36, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This one is
pretty much good to go, unless something disastrous crops up.
http://ftp.digitalmars.com/dmd2beta.zip
All directories have executable permission set.
--
/Jacob Carlborg
On 5/22/2013 11:55 PM, Jacob Carlborg wrote:
On 2013-05-21 22:36, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This one is
pretty much good to go, unless something disastrous crops up.
http://ftp.digitalmars.com/dmd2beta.zip
All directories have executable
On 2013-05-23 09:08, Walter Bright wrote:
Is this the case with previous zips, or is it new for this one?
Never mind. It was my tool. I tried a different one and it's not
executable there.
--
/Jacob Carlborg
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This
one is pretty much good to go, unless something disastrous
crops up.
http://ftp.digitalmars.com/dmd2beta.zip
Remaining regressions:
just filed a regression from 062 to 063:
http://d.puremagic.com/issues/show_bug.cgi?id=10141
it only affects error message though (giving a nonsensical error message).
Digression:
I used dustmite to reduce it (awesome tool) down to 6 files, but then had
to further manually reduce to 1 file.
I
On Thursday, 23 May 2013 at 09:05:02 UTC, Don wrote:
This means that the const variable x has been initialized TWICE!
That's no different from non-const members.
struct Foo { int x = 1; }
Foo f = Foo(2); // f.x is 2
The initialiser is a default value if you don't provide one in
the
On 05/23/13 11:05, Don wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This one is pretty
much good to go, unless something disastrous crops up.
http://ftp.digitalmars.com/dmd2beta.zip
Remaining regressions:
On 21 May 2013 21:36, Walter Bright newshou...@digitalmars.com wrote:
Join the dmd beta mailing list to keep up with the betas. This one is pretty
much good to go, unless something disastrous crops up.
http://ftp.digitalmars.com/dmd2beta.zip
Remaining regressions:
and another regression, this time more serious, that came up in my code:
http://d.puremagic.com/issues/show_bug.cgi?id=10148
Note, dustmite got stuck forever trying to reduce it, so i had to reduce
manually.
On Tue, May 21, 2013 at 1:36 PM, Walter Bright
newshou...@digitalmars.comwrote:
On Thursday, 23 May 2013 at 10:17:00 UTC, Peter Alexander wrote:
On Thursday, 23 May 2013 at 09:05:02 UTC, Don wrote:
This means that the const variable x has been initialized
TWICE!
That's no different from non-const members.
It's perfectly OK to modify a non-const member as many times as
On Thursday, 23 May 2013 at 11:33:53 UTC, Timothee Cour wrote:
Note, dustmite got stuck forever trying to reduce it, so i had
to reduce
manually.
You may need to use Dustmite together with the timeout command
for cases when the test command may hang indefinitely:
On Thursday, 23 May 2013 at 11:08:16 UTC, Artur Skawina wrote:
On 05/23/13 11:05, Don wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas.
This one is pretty much good to go, unless something
disastrous crops up.
On 05/23/13 15:12, Don wrote:
On Thursday, 23 May 2013 at 11:08:16 UTC, Artur Skawina wrote:
On 05/23/13 11:05, Don wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This one is
pretty much good to go, unless
On Thu, 23 May 2013 05:05:01 -0400, Don turnyourkidsintoc...@nospam.com
wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This one is
pretty much good to go, unless something disastrous crops up.
On Thu, 23 May 2013 09:50:28 -0400, Artur Skawina art.08...@gmail.com
wrote:
On 05/23/13 15:12, Don wrote:
On Thursday, 23 May 2013 at 11:08:16 UTC, Artur Skawina wrote:
struct Packet(uint TYPE) {
immutable uint type = TYPE;
// ...
}
But that allows you to write:
auto w =
On 23 May 2013 14:52, Steven Schveighoffer schvei...@yahoo.com wrote:
On Thu, 23 May 2013 05:05:01 -0400, Don turnyourkidsintoc...@nospam.com
wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This one is
pretty
something I may have actually used in real code writing a
low-level networking library:
struct Packet
{
immutable etherType = 0x0800; // IPv4 by default;
// ...
this(bool IPv6)
{
if (!IPv6)
return; // fine
On Thu, May 23, 2013 at 4:42 PM, Dicebot m.stras...@gmail.com wrote:
something I may have actually used in real code writing a low-level
networking library:
...
default template argument would sort that out wouldn't it?
On Thursday, 23 May 2013 at 14:58:01 UTC, Steven Schveighoffer
wrote:
Seems like const qualifier for members is simply ignored inside
the ctor, it should only be ignored until it is set, or until
it is used.
I am quite sure I have seen it (mutability of immutable in
constructor) guaranteed
On Thursday, 23 May 2013 at 09:35:03 UTC, Timothee Cour wrote:
I wish dustmite could be improved to 'run the last mile' by
attempting to
merge files:
a.d:
import b;
b.d:
import c;
c.d:
//some stuff
dustmite should attempt to merge such files and reduce to:
a.d
// some stuff
Added!
On Thu, 23 May 2013 11:07:16 -0400, Dicebot m.stras...@gmail.com wrote:
On Thursday, 23 May 2013 at 14:58:01 UTC, Steven Schveighoffer wrote:
Seems like const qualifier for members is simply ignored inside the
ctor, it should only be ignored until it is set, or until it is used.
I am quite
On Thursday, 23 May 2013 at 14:58:01 UTC, Steven Schveighoffer
wrote:
On Thu, 23 May 2013 10:16:13 -0400, Iain Buclaw
ibuc...@ubuntu.com wrote:
On 23 May 2013 14:52, Steven Schveighoffer
schvei...@yahoo.com wrote:
Adding an initializer simply changes the default value from 0
to whatever
On Thu, May 23, 2013 at 5:06 PM, Dicebot m.stras...@gmail.com wrote:
On Thursday, 23 May 2013 at 14:56:14 UTC, Rory McGuire wrote:
On Thu, May 23, 2013 at 4:42 PM, Dicebot m.stras...@gmail.com wrote:
b) it requires to know your argument at compile-time. What if you packet
construction is
On 05/23/13 16:02, Steven Schveighoffer wrote:
On Thu, 23 May 2013 09:50:28 -0400, Artur Skawina art.08...@gmail.com wrote:
On 05/23/13 15:12, Don wrote:
On Thursday, 23 May 2013 at 11:08:16 UTC, Artur Skawina wrote:
struct Packet(uint TYPE) {
immutable uint type = TYPE;
// ...
}
On Thursday, 23 May 2013 at 13:52:49 UTC, Steven Schveighoffer
wrote:
On Thu, 23 May 2013 05:05:01 -0400, Don
turnyourkidsintoc...@nospam.com wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas.
This one is pretty
On Thu, 23 May 2013 11:36:00 -0400, Artur Skawina art.08...@gmail.com
wrote:
If it wasn't clear - it is about the _language_, not what some compiler
currently happens to do. Being able to mutate /initialized/ immutables
is a bad idea. IOW you should not be able to modify 'Packet.type' above.
On 23 May 2013 19:05, Don turnyourkidsintoc...@nospam.com wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This one is
pretty much good to go, unless something disastrous crops up.
On Thu, 23 May 2013 12:09:26 -0400, Don turnyourkidsintoc...@nospam.com
wrote:
On Thursday, 23 May 2013 at 13:52:49 UTC, Steven Schveighoffer wrote:
On Thu, 23 May 2013 05:05:01 -0400, Don
turnyourkidsintoc...@nospam.com wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This
one is pretty much good to go, unless something disastrous
crops up.
http://ftp.digitalmars.com/dmd2beta.zip
Remaining regressions:
On 5/23/13 9:12 AM, Don wrote:
No, it's not, it's a fix plus a new misfeature.
Don, you're wrong. The feature is sensible. The problem with it is that
it changes semantics of existing code.
Andrei
On 5/23/13 11:07 AM, Dicebot wrote:
On Thursday, 23 May 2013 at 14:58:01 UTC, Steven Schveighoffer wrote:
Seems like const qualifier for members is simply ignored inside the
ctor, it should only be ignored until it is set, or until it is used.
I am quite sure I have seen it (mutability of
Am Thu, 23 May 2013 13:06:44 -0400
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
TDPL 8.4 discusses a raw/cooked model of construction. The same
principle should apply to const/immutable member construction: you get
to cook the field, but you can't taste it while raw.
You are
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This
one is pretty much good to go, unless something disastrous
crops up.
http://ftp.digitalmars.com/dmd2beta.zip
Is it possible to change zip filename from
On 5/23/13 2:08 PM, Marco Leise wrote:
Am Thu, 23 May 2013 13:06:44 -0400
schrieb Andrei Alexandrescuseewebsiteforem...@erdani.org:
TDPL 8.4 discusses a raw/cooked model of construction. The same
principle should apply to const/immutable member construction: you get
to cook the field, but you
On 05/23/13 18:26, Steven Schveighoffer wrote:
On Thu, 23 May 2013 11:36:00 -0400, Artur Skawina art.08...@gmail.com wrote:
If it wasn't clear - it is about the _language_, not what some compiler
currently happens to do. Being able to mutate /initialized/ immutables
is a bad idea. IOW you
On Thu, 23 May 2013 16:42:30 -0400, Artur Skawina art.08...@gmail.com
wrote:
On 05/23/13 18:26, Steven Schveighoffer wrote:
On Thu, 23 May 2013 11:36:00 -0400, Artur Skawina art.08...@gmail.com
wrote:
If it wasn't clear - it is about the _language_, not what some compiler
currently
On Thu, 23 May 2013 17:06:57 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Thu, 23 May 2013 16:42:30 -0400, Artur Skawina art.08...@gmail.com
wrote:
For example you couldn't then do this:
struct Packet(uint TY) { /*...*/immutable uint type=TY; immutable ubyte
len=PLen(TY);
On 5/23/2013 4:07 AM, Iain Buclaw wrote:
On 21 May 2013 21:36, Walter Bright newshou...@digitalmars.com wrote:
Join the dmd beta mailing list to keep up with the betas. This one is pretty
much good to go, unless something disastrous crops up.
http://ftp.digitalmars.com/dmd2beta.zip
Remaining
On 5/23/13, Vladimir Panteleev vladi...@thecybershadow.net wrote:
2) it doesn't know which file is the main
program file (the file which must be present for the test script
to succeed), if there is one.
Does https://github.com/D-Programming-Language/dmd/pull/1732 help? It
was merged a while
On 5/23/2013 2:05 AM, Don wrote:
NO NO NO NO. I am violently opposed to this release.
This beta contains the worst language misfeature of all time. It's silently
snuck in under the guise of a bugfix.
Don has an excellent point. His case is bolstered by this causing Tango2 to fail
to compile
On Thu, 23 May 2013 19:03:25 -0400, Artur Skawina art.08...@gmail.com
wrote:
On 05/23/13 23:06, Steven Schveighoffer wrote:
compiles:
struct S
{
const int x;
this(int n)
{
x = n;
}
}
It's the 'const int x = 42;' case we're talking about. *That* one does
not
compile and
On Thu, 23 May 2013 20:01:19 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 5/23/2013 2:05 AM, Don wrote:
NO NO NO NO. I am violently opposed to this release.
This beta contains the worst language misfeature of all time. It's
silently
snuck in under the guise of a bugfix.
Walter Bright:
Therefore, I propose the following addition of a warning:
--
const int q = 5;
Warning: const field with initializer should be static or enum.
--
Over time, this can be upgraded to a deprecation and then an
error.
On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:
What about making it an error UNLESS you pass a compiler flag. The user will be
informed, and the new behavior (which I find useful) is possible.
While that idea has significant merit, I oppose it on the following grounds:
1. It forces a very
On 5/23/13 8:56 PM, Walter Bright wrote:
On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:
What about making it an error UNLESS you pass a compiler flag. The
user will be
informed, and the new behavior (which I find useful) is possible.
While that idea has significant merit, I oppose it on
On 5/23/2013 5:56 PM, Walter Bright wrote:
On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:
What about making it an error UNLESS you pass a compiler flag. The user will be
informed, and the new behavior (which I find useful) is possible.
While that idea has significant merit, I oppose it on
On 5/23/2013 6:01 PM, Andrei Alexandrescu wrote:
On 5/23/13 8:56 PM, Walter Bright wrote:
On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:
What about making it an error UNLESS you pass a compiler flag. The
user will be
informed, and the new behavior (which I find useful) is possible.
While
Walter Bright:
3. Naive users may see their compile fail, see a switch to
'enable' it, and throw the switch. Now it compiles, but fails
silently at runtime. This is because the new behavior is quite
different from the old, and the code that relies on the old
behavior will most likely need to
On 5/23/2013 7:35 PM, bearophile wrote:
Walter Bright:
3. Naive users may see their compile fail, see a switch to 'enable' it, and
throw the switch. Now it compiles, but fails silently at runtime. This is
because the new behavior is quite different from the old, and the code that
relies on the
On 5/23/2013 7:57 PM, bearophile wrote:
Walter Bright:
Even if such naive D programmers exist, maybe it's better to ignore this third
point, because they will not be able to program in D for other reasons.
s/naive/tired/
s/naive/inahurry/
I'm surprised at you, bearophile!
A safe and well
On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:
On Thu, 23 May 2013 21:56:47 -0400, Walter Bright newshou...@digitalmars.com
wrote:
On 5/23/2013 5:56 PM, Walter Bright wrote:
On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:
What about making it an error UNLESS you pass a compiler flag.
On Friday, 24 May 2013 at 03:38:33 UTC, Walter Bright wrote:
For now, it is the proper path. The warning is that change is
coming, but you have time to fix it.
Yes, with an explanation how to fix it, maybe a link to a webpage
that explain why the change is made, etc . . .
On Thu, 23 May 2013 23:38:32 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:
This is one change where ALL code broken by this change
is fixable with a simple solution, and at some point, people will have
to deal
with this.
Yes,
On 5/23/2013 8:53 PM, Steven Schveighoffer wrote:
On Thu, 23 May 2013 23:38:32 -0400, Walter Bright newshou...@digitalmars.com
wrote:
On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:
This is one change where ALL code broken by this change
is fixable with a simple solution, and at some point,
On 5/23/2013 11:17 PM, Walter Bright wrote:
On 5/23/2013 8:53 PM, Steven Schveighoffer wrote:
On Thu, 23 May 2013 23:38:32 -0400, Walter Bright
newshou...@digitalmars.com
wrote:
On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:
This is one change where ALL code broken by this change
is
Join the dmd beta mailing list to keep up with the betas. This one is pretty
much good to go, unless something disastrous crops up.
http://ftp.digitalmars.com/dmd2beta.zip
Remaining regressions:
On Wednesday, 22 May 2013 at 04:45:57 UTC, kdmult wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This
one is pretty much good to go, unless something disastrous
crops up.
http://ftp.digitalmars.com/dmd2beta.zip
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This
one is pretty much good to go, unless something disastrous
crops up.
http://ftp.digitalmars.com/dmd2beta.zip
windows/bin/d.chm was generated using version 2.058, so
88 matches
Mail list logo
