On Tuesday, 21 May 2013 at 01:34:29 UTC, estew wrote:
But I'm not convinced it would cost us less to have NotNull!T
and Nullable!T. I feel it is cheaper to mindlessly write if(a
is null) {} when using pointers than to worry at design time
what the behaviour of a pointer should be.
As a
I know at least two cases which T.init is commonly used.
1. Inside predicate template for type T.
template isSomething(T) {
enum isSomething = is(typeof({
//T t1;// not good if T is nested struct, or has @disable this()
//T t2 = void; auto x = t2; // not good if T is
On Monday, 20 May 2013 at 06:10:22 UTC, Kenji Hara wrote:
I know at least two cases which T.init is commonly used.
1. Inside predicate template for type T.
template isSomething(T) {
enum isSomething = is(typeof({
//T t1;// not good if T is nested struct, or has
@disable this()
On Sunday, 19 May 2013 at 21:36:17 UTC, Andrei Alexandrescu wrote:
OK, this is sensible. One question - would you be willing to
type symbols as NullType!T instead of T to avoid these issues?
Good question. Probably not. I think it's one of those things
were the awkwardness of it not being the
On Sun, 19 May 2013 21:02:11 +0200, Idan Arye generic...@gmail.com wrote:
I don't see how Option and Maybe would have helped your bug. The problem
was that somewhere in the code the reference was perceived as null while
in fact it wasn't
What does that even mean?
- so now it will be
On Sun, 19 May 2013 20:05:02 +0200, Idan Arye generic...@gmail.com wrote:
These are the assumptions I'm working with:
- We can't use a nullable reference
- We can't initialize the reference upon declaration to it's real
value.
Indeed, if that's the case, then what you're doing is fairly
On Sun, 19 May 2013 20:23:21 +0200, Walter Bright
newshou...@digitalmars.com wrote:
On 5/19/2013 5:02 AM, Simen Kjaeraas wrote:
By definition? Pointer semantics are what we choose it to mean.
Of course. But which definition is saner:
For many types, it is extremely useful to have some
I'm surprised people still have problems with null pointers. I
for one am glad D has null by default makes life easy coming from
C++ and Java.
I may have missed something but what happens with the following
code if I could not have a null pointer?
int*[] pntrs = new int*[10];
Would I need
On Monday, 20 May 2013 at 14:49:32 UTC, estew wrote:
Now I want to access a pointer, write code using it etc. But I
need to manually track at development time whether it is
NotNull!T, Null!T, Maybe!T, Option!T or whatever. I cannot just
have a pointer anymore, knowing it's initialised to null.
On Sun, 19 May 2013 17:36:17 -0400, Andrei Alexandrescu wrote:
On 5/19/13 4:30 PM, Peter Alexander wrote:
On Sunday, 19 May 2013 at 20:03:24 UTC, Andrei Alexandrescu wrote:
You are blowing it out of proportion. Null references are hardly even
on the radar of the bug classes I'm encountering
On 5/19/13 8:46 PM, Steven Schveighoffer wrote:
I just wanted to chime in with this understanding of the bug that I am
reading from deadalnix's descriptions:
SomeObj obj;
shareTheObj(obj); // goes to other threads
obj = new SomeObj; // initialize obj
This is likely simpler than the actual
On 5/20/13 11:19 AM, Byron Heads wrote:
On Sun, 19 May 2013 17:36:17 -0400, Andrei Alexandrescu wrote:
OK, this is sensible. One question - would you be willing to type
symbols as NullType!T instead of T to avoid these issues?
Thanks,
Andrei
More boiler plate code for functions that take
On Mon, 20 May 2013 11:43:35 -0400, Andrei Alexandrescu wrote:
On 5/20/13 11:19 AM, Byron Heads wrote:
On Sun, 19 May 2013 17:36:17 -0400, Andrei Alexandrescu wrote:
OK, this is sensible. One question - would you be willing to type
symbols as NullType!T instead of T to avoid these issues?
On Sun, 19 May 2013 05:17:57 +0200, Walter Bright
newshou...@digitalmars.com wrote:
On 5/18/2013 1:39 PM, Walter Bright wrote:
Already reported:
http://d.puremagic.com/issues/show_bug.cgi?id=10115
And Kenji has already posted a fix!
What can I say, other than Awesome!
Great! One more:
On Mon, 20 May 2013 18:05:18 +0200, Byron Heads byron.he...@gmail.com
wrote:
What about dealing with externs you want to protect?
extern(C) void foo(@nonnull int* x);
There is nothing stopping you from declaring that with this signature:
extern(C) void foo(NonNull!(int*) x);
--
Simen
On Monday, 20 May 2013 at 00:55:14 UTC, Kenji Hara wrote:
Unfortunately this is currently not a bug.
T.init provides default initialized object image, and it
*does not*
provide default constructed object. The difference is
important.
That is already documented in lanugage reference.
On Monday, 20 May 2013 at 14:57:17 UTC, Dicebot wrote:
On Monday, 20 May 2013 at 14:49:32 UTC, estew wrote:
Now I want to access a pointer, write code using it etc. But I
need to manually track at development time whether it is
NotNull!T, Null!T, Maybe!T, Option!T or whatever. I cannot
just
On Saturday, May 18, 2013 22:04:08 Walter Bright wrote:
On 5/18/2013 9:42 PM, Jonathan M Davis wrote:
On Saturday, May 18, 2013 21:30:57 Walter Bright wrote:
On 5/18/2013 9:06 PM, Jonathan M Davis wrote:
The closest that there is is
C++'s references, which aren't rebindable and in many
On Sun, 19 May 2013 06:57:16 +0200, Walter Bright
newshou...@digitalmars.com wrote:
The current solution is to rely on faith, and I remember someone
talking about
that at DConf recently.
Rely on what faith?
void foo(int* p) {} // p must never be null
void foo(NotNull!(int*) p) {}
One
On Sun, 19 May 2013 02:32:49 +0200, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Sunday, May 19, 2013 02:22:43 Simen Kjaeraas wrote:
Or... possibly, the current holes in @disable are fixed, and NonNull!T
becomes the default, because we tell people to always use them, rather
than flail our
On 05/19/2013 06:57 AM, Walter Bright wrote:
D already have thing like Nullable in the standard lib. Introducing
Maybe is
also pretty easy. Adding NonNullable in addition to Nullable sound like
something is not quite right.
Nullable is something different - it exists to give a 'null' value to
On Sunday, 19 May 2013 at 12:06:01 UTC, Simen Kjaeraas wrote:
My experience is the complete opposite - I think maybe 20% of
bugs at my job
are caused by null references. But as you say, they are very
easily fixed.
Sometime they are super freaking hard. I have a horror story
debugging
On 5/19/13 8:55 AM, deadalnix wrote:
On Sunday, 19 May 2013 at 12:06:01 UTC, Simen Kjaeraas wrote:
My experience is the complete opposite - I think maybe 20% of bugs at
my job
are caused by null references. But as you say, they are very easily
fixed.
Sometime they are super freaking hard. I
On Sunday, 19 May 2013 at 13:08:53 UTC, Andrei Alexandrescu wrote:
Sounds like a race problem unrelated to null. With non-null
objects the race would have manifested itself in a different
way, perhaps even more pernicious.
It is both a race condition and a null problem. And having non
On 5/19/13 9:11 AM, deadalnix wrote:
On Sunday, 19 May 2013 at 13:08:53 UTC, Andrei Alexandrescu wrote:
Sounds like a race problem unrelated to null. With non-null objects
the race would have manifested itself in a different way, perhaps even
more pernicious.
It is both a race condition and
On Sunday, 19 May 2013 at 13:13:07 UTC, Andrei Alexandrescu wrote:
On 5/19/13 9:11 AM, deadalnix wrote:
On Sunday, 19 May 2013 at 13:08:53 UTC, Andrei Alexandrescu
wrote:
Sounds like a race problem unrelated to null. With non-null
objects
the race would have manifested itself in a different
On Sunday, 19 May 2013 at 13:13:07 UTC, Andrei Alexandrescu wrote:
On 5/19/13 9:11 AM, deadalnix wrote:
It is both a race condition and a null problem.
No, it's just a race condition.
And having non nullable
type would have been a compile time error instead of days of
debugging.
No, the
On Sunday, 19 May 2013 at 04:57:15 UTC, Walter Bright wrote:
On 5/18/2013 8:54 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 01:20:31 UTC, Walter Bright wrote:
I understand that. But the rationale you gave for having a
default constructor
was to be able to disable default construction.
On Sun, 19 May 2013 19:12:15 +0200, Idan Arye generic...@gmail.com wrote:
It's a good practice to initialize references(and all other types of
variables) as soon as possible - and if possible, right away in the
declaration. If that reference started as null, it's safe to assume it
was not
On Sunday, 19 May 2013 at 17:35:43 UTC, deadalnix wrote:
Idan Arye Nil proposal make no sens in a statically typed
language. And you'll find no better kind of null. We have all
tools we need in D to work around null in library.
That's not the point. The point is that if you couldn't
On Sunday, 19 May 2013 at 17:46:13 UTC, Simen Kjaeraas wrote:
On Sun, 19 May 2013 19:12:15 +0200, Idan Arye
generic...@gmail.com wrote:
It's a good practice to initialize references(and all other
types of variables) as soon as possible - and if possible,
right away in the declaration. If
On Sunday, 19 May 2013 at 17:51:36 UTC, Idan Arye wrote:
On Sunday, 19 May 2013 at 17:35:43 UTC, deadalnix wrote:
Idan Arye Nil proposal make no sens in a statically typed
language. And you'll find no better kind of null. We have all
tools we need in D to work around null in library.
That's
On Sunday, 19 May 2013 at 18:05:03 UTC, Idan Arye wrote:
These are the assumptions I'm working with:
- We can't use a nullable reference
- We can't initialize the reference upon declaration to it's
real value.
If you can't initialize the value, you got to assume when you use
it that it
On 5/19/2013 5:02 AM, Simen Kjaeraas wrote:
By definition? Pointer semantics are what we choose it to mean.
Of course. But which definition is saner:
For many types, it is extremely useful to have some sort of invalid value for
it. null fills that role nicely for pointers, just as nan does
On 5/19/2013 10:41 AM, deadalnix wrote:
I have bunch of code that goes like :
auto oldVar = var;
scope(exit) var = oldVar;
This is begging for a RAII solution where I pass var as template parameter but
would require default constructor. This is an actual problem I have right now as
all
On Sunday, 19 May 2013 at 18:23:22 UTC, Walter Bright wrote:
On 5/19/2013 5:02 AM, Simen Kjaeraas wrote:
By definition? Pointer semantics are what we choose it to
mean.
Of course. But which definition is saner:
For many types, it is extremely useful to have some sort of
invalid value for
On Sunday, 19 May 2013 at 18:27:08 UTC, Walter Bright wrote:
oldVar isn't being default constructed in your example, nor can
I see why you'd need a default constructor in order to use RAII
for save/restore.
I need to save the value at construction and restore at
destruction. I don't need any
On 5/19/2013 10:35 AM, deadalnix wrote:
On Sunday, 19 May 2013 at 13:13:07 UTC, Andrei Alexandrescu wrote:
No, the race condition would have stayed.
That is ridiculous. non nullable would have made the bug non existent, and even
without race condition the problem would exists. a reference is
On 2013-05-19 19:41, deadalnix wrote:
I have bunch of code that goes like :
auto oldVar = var;
scope(exit) var = oldVar;
This is begging for a RAII solution where I pass var as template
parameter but would require default constructor. This is an actual
problem I have right now as all
On Sunday, 19 May 2013 at 18:22:16 UTC, deadalnix wrote:
On Sunday, 19 May 2013 at 18:05:03 UTC, Idan Arye wrote:
These are the assumptions I'm working with:
- We can't use a nullable reference
- We can't initialize the reference upon declaration to it's
real value.
If you can't initialize
On 5/19/13 1:41 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 04:57:15 UTC, Walter Bright wrote:
On 5/18/2013 8:54 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 01:20:31 UTC, Walter Bright wrote:
I understand that. But the rationale you gave for having a default
constructor
was to be able
On Sunday, 19 May 2013 at 18:46:31 UTC, Walter Bright wrote:
You also never provided any convincing solution to the safety
hole. We can't
even add check only on some edges cases as D also have values
types. The only
solution we are left with that is really safe is to null check
every
On 5/19/13 1:12 PM, Idan Arye wrote:
On Sunday, 19 May 2013 at 13:13:07 UTC, Andrei Alexandrescu wrote:
On 5/19/13 9:11 AM, deadalnix wrote:
On Sunday, 19 May 2013 at 13:08:53 UTC, Andrei Alexandrescu wrote:
Sounds like a race problem unrelated to null. With non-null objects
the race would
On 5/19/13 1:35 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 13:13:07 UTC, Andrei Alexandrescu wrote:
On 5/19/13 9:11 AM, deadalnix wrote:
It is both a race condition and a null problem.
No, it's just a race condition.
And having non nullable
type would have been a compile time error
On Saturday, 18 May 2013 at 20:39:29 UTC, Walter Bright wrote:
On 5/18/2013 1:22 PM, deadalnix wrote:
Many are, but I think that isn't the point we are discussing
here.
Removing all holes in @disable this will require the same
sacrifices at the ends
than default constructor would. For
On 5/19/13 3:10 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 18:46:31 UTC, Walter Bright wrote:
You also never provided any convincing solution to the safety hole.
We can't
even add check only on some edges cases as D also have values types.
The only
solution we are left with that is really
On Sunday, 19 May 2013 at 18:30:09 UTC, deadalnix wrote:
void buzz(Foo f) {
f.foo(); // Rely in faith. It is invalid and way easier to
write than the valid code, which is THE recipe for it to spread.
}
Shouldn't this throw a NullPointerSomething?
On Sunday, 19 May 2013 at 19:10:28 UTC, Andrei Alexandrescu wrote:
No, your argument is ridiculous. You make a yarn with precious
little detail that describes for everything everyone knows a
textbook race condition, essentially ask that you are taking by
your word that non-null would
On Sunday, 19 May 2013 at 19:15:47 UTC, Andrei Alexandrescu wrote:
Oh, the good old object of sufficient size. We know how to
fix that.
And no, putting nullcheck on access of field of sufficient
offset (as
propose dby Andrei) isn't enough because we have value types.
Consider :
On 5/19/2013 12:13 PM, Maxim Fomin wrote:
Since in system language there is plenty of ways to deliberately pass invalid
data to the place where some validity assumptions were made, @disable is a
broken feature.
Please report all such holes to bugzilla.
On 5/19/2013 12:31 PM, Minas Mina wrote:
On Sunday, 19 May 2013 at 18:30:09 UTC, deadalnix wrote:
void buzz(Foo f) {
f.foo(); // Rely in faith. It is invalid and way easier to write than the
valid code, which is THE recipe for it to spread.
}
Shouldn't this throw a NullPointerSomething?
On 05/19/2013 09:10 PM, Andrei Alexandrescu wrote:
On 5/19/13 1:35 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 13:13:07 UTC, Andrei Alexandrescu wrote:
On 5/19/13 9:11 AM, deadalnix wrote:
It is both a race condition and a null problem.
No, it's just a race condition.
And having non
On 5/19/13 3:41 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 19:15:47 UTC, Andrei Alexandrescu wrote:
Oh, the good old object of sufficient size. We know how to fix that.
And no, putting nullcheck on access of field of sufficient offset (as
propose dby Andrei) isn't enough because we have
On 05/19/2013 09:42 PM, Walter Bright wrote:
On 5/19/2013 12:31 PM, Minas Mina wrote:
On Sunday, 19 May 2013 at 18:30:09 UTC, deadalnix wrote:
void buzz(Foo f) {
f.foo(); // Rely in faith. It is invalid and way easier to write
than the
valid code, which is THE recipe for it to spread.
}
On 5/19/2013 11:37 AM, deadalnix wrote:
On Sunday, 19 May 2013 at 18:27:08 UTC, Walter Bright wrote:
oldVar isn't being default constructed in your example, nor can I see why
you'd need a default constructor in order to use RAII for save/restore.
I need to save the value at construction and
On 05/19/2013 09:10 PM, Andrei Alexandrescu wrote:
I encourage you to look at this :
http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
I read it. I don't buy it. Yeah, it's a point, but it's largely
exaggerated for dramatic purposes.
(It is a talk.)
On 5/19/13 3:36 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 19:10:28 UTC, Andrei Alexandrescu wrote:
No, your argument is ridiculous. You make a yarn with precious little
detail that describes for everything everyone knows a textbook race
condition, essentially ask that you are taking by
On Sunday, 19 May 2013 at 19:42:59 UTC, Walter Bright wrote:
On 5/19/2013 12:31 PM, Minas Mina wrote:
On Sunday, 19 May 2013 at 18:30:09 UTC, deadalnix wrote:
void buzz(Foo f) {
f.foo(); // Rely in faith. It is invalid and way easier to
write than the
valid code, which is THE recipe for
On 5/19/2013 12:10 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 18:46:31 UTC, Walter Bright wrote:
You also never provided any convincing solution to the safety hole. We can't
even add check only on some edges cases as D also have values types. The only
solution we are left with that is
On 5/19/13 3:58 PM, Timon Gehr wrote:
On 05/19/2013 09:10 PM, Andrei Alexandrescu wrote:
I encourage you to look at this :
http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
I read it. I don't buy it. Yeah, it's a point, but it's largely
exaggerated for
On 5/19/13 4:05 PM, Walter Bright wrote:
On 5/19/2013 12:10 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 18:46:31 UTC, Walter Bright wrote:
You also never provided any convincing solution to the safety hole.
We can't
even add check only on some edges cases as D also have values types.
The
On Sunday, 19 May 2013 at 20:03:24 UTC, Andrei Alexandrescu wrote:
Well you got to do what you got to do. Field accesses for
objects larger than 4KB would have to be checked in @safe code.
Isn't the solution as easy as doing:
OR PTR:[address], 0
the same way it's done for the stack?
The
On 5/19/2013 12:36 PM, deadalnix wrote:
I C or C++ you are doomed to manage reference as you need to for memory
management purpose. In garbage collected languages, you ends up with way more
unmanaged references, because the GC take care of them. Doing so you multiply
the surface area where null
On Sunday, 19 May 2013 at 20:03:24 UTC, Andrei Alexandrescu wrote:
You are blowing it out of proportion. Null references are
hardly even on the radar of the bug classes I'm encountering in
the style of programming of the three groups I worked in at
Facebook, and also my previous employers.
On 5/19/2013 1:06 PM, Andrei Alexandrescu wrote:
On 5/19/13 3:58 PM, Timon Gehr wrote:
(It is a talk.)
(I read a transcript.)
I wish more talks had transcripts available. I can read an hour talk
presentation in 5 minutes.
On 5/19/2013 1:08 PM, Mr. Anonymous wrote:
On Sunday, 19 May 2013 at 20:03:24 UTC, Andrei Alexandrescu wrote:
Well you got to do what you got to do. Field accesses for objects larger than
4KB would have to be checked in @safe code.
Isn't the solution as easy as doing:
OR PTR:[address], 0
the
On 5/19/2013 1:03 PM, Maxim Fomin wrote:
I think there is difference between catching exception and saving
data which you have typed for some period and letting harware
check the exception for you meanwile loosing your work.
You can catch seg faults. It's easier on Windows, but it's doable on
On 5/19/2013 11:22 AM, deadalnix wrote:
The damn thing should have been initialized in the
first place to avoid the bug.
Sounds like you have the double-checked locking bug. Using a different value to
initialize it won't fix it.
If you have a global value accessible from multiple threads,
On 5/19/2013 2:02 PM, Walter Bright wrote:
If you have a global value accessible from multiple threads, you must use
synchronization. There is no way around that. If you use some other global state
to check for initialization in order to avoid synchronization, you have the
double checked locking
On 5/19/13 4:30 PM, Peter Alexander wrote:
On Sunday, 19 May 2013 at 20:03:24 UTC, Andrei Alexandrescu wrote:
You are blowing it out of proportion. Null references are hardly even
on the radar of the bug classes I'm encountering in the style of
programming of the three groups I worked in at
On Sunday, 19 May 2013 at 20:03:24 UTC, Andrei Alexandrescu wrote:
On 5/19/13 3:36 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 19:10:28 UTC, Andrei Alexandrescu
wrote:
No, your argument is ridiculous. You make a yarn with
precious little
detail that describes for everything everyone knows a
On Sunday, 19 May 2013 at 21:02:57 UTC, Walter Bright wrote:
On 5/19/2013 11:22 AM, deadalnix wrote:
The damn thing should have been initialized in the
first place to avoid the bug.
Sounds like you have the double-checked locking bug. Using a
different value to initialize it won't fix it.
On Sunday, 19 May 2013 at 20:30:28 UTC, Peter Alexander wrote:
On Sunday, 19 May 2013 at 20:03:24 UTC, Andrei Alexandrescu
wrote:
You are blowing it out of proportion. Null references are
hardly even on the radar of the bug classes I'm encountering
in the style of programming of the three
On Sunday, 19 May 2013 at 21:36:17 UTC, Andrei Alexandrescu wrote:
On 5/19/13 4:30 PM, Peter Alexander wrot
OK, this is sensible. One question - would you be willing to
type symbols as NullType!T instead of T to avoid these issues?
Thanks,
Andrei
Trying to come up with some
On 5/19/13 5:11 PM, Walter Bright wrote:
It reminded me of the hours I spent in high school determined to show
that I could trisect an angle with a compass and a straightedge. There
was always some tiny flaw :-)
Yah, sounds familiar. Did you prove the parallel postulate, too?
Andrei
On 5/19/13 5:56 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 21:02:57 UTC, Walter Bright wrote:
On 5/19/2013 11:22 AM, deadalnix wrote:
The damn thing should have been initialized in the
first place to avoid the bug.
Sounds like you have the double-checked locking bug. Using a different
On 5/19/13 5:52 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 20:03:24 UTC, Andrei Alexandrescu wrote:
On 5/19/13 3:36 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 19:10:28 UTC, Andrei Alexandrescu wrote:
No, your argument is ridiculous. You make a yarn with precious little
detail that
On Sunday, 19 May 2013 at 22:32:58 UTC, Andrei Alexandrescu wrote:
How was there a bug if everything was properly synchronized?
You either describe the matter with sufficient detail, or
acknowledge the destruction of your anecdote. This is going
nowhere.
I explained over and over. A field
On 5/19/2013 3:30 PM, Andrei Alexandrescu wrote:
On 5/19/13 5:11 PM, Walter Bright wrote:
It reminded me of the hours I spent in high school determined to show
that I could trisect an angle with a compass and a straightedge. There
was always some tiny flaw :-)
Yah, sounds familiar. Did you
On 5/19/2013 4:06 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 22:32:58 UTC, Andrei Alexandrescu wrote:
How was there a bug if everything was properly synchronized? You either
describe the matter with sufficient detail, or acknowledge the destruction of
your anecdote. This is going nowhere.
On 5/19/13 7:06 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 22:32:58 UTC, Andrei Alexandrescu wrote:
How was there a bug if everything was properly synchronized? You
either describe the matter with sufficient detail, or acknowledge the
destruction of your anecdote. This is going nowhere.
On Sunday, May 19, 2013 09:08:53 Andrei Alexandrescu wrote:
Anyhow, this discussion should have finality. We could go on forever
arguing the usefulness or lack thereof of non-nullable references. They
didn't catch up in some languages and did in some. My personal opinion
is nice to have, but
On 5/19/2013 3:04 PM, deadalnix wrote:
Same argument Walter like to make about very rare failure cases apply here.
1. rare as in programmers rarely create such a bug
2. rare as in being rare for an existing bug to show itself
I was referring to (1), while you are referring to (2).
On Sunday, 19 May 2013 at 23:07:00 UTC, deadalnix wrote:
On Sunday, 19 May 2013 at 22:32:58 UTC, Andrei Alexandrescu
wrote:
How was there a bug if everything was properly synchronized?
You either describe the matter with sufficient detail, or
acknowledge the destruction of your anecdote. This
On Sunday, 19 May 2013 at 20:45:39 UTC, Walter Bright wrote:
On 5/19/2013 1:03 PM, Maxim Fomin wrote:
I think there is difference between catching exception and
saving
data which you have typed for some period and letting harware
check the exception for you meanwile loosing your work.
You
On Sunday, 19 May 2013 at 23:29:53 UTC, Walter Bright wrote:
On 5/19/2013 4:06 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 22:32:58 UTC, Andrei Alexandrescu
wrote:
How was there a bug if everything was properly synchronized?
You either
describe the matter with sufficient detail, or
On Monday, 20 May 2013 at 00:23:59 UTC, John Colvin wrote:
On Sunday, 19 May 2013 at 20:45:39 UTC, Walter Bright wrote:
On 5/19/2013 1:03 PM, Maxim Fomin wrote:
I think there is difference between catching exception and
saving
data which you have typed for some period and letting harware
On Monday, 20 May 2013 at 00:09:23 UTC, Walter Bright wrote:
On 5/19/2013 3:04 PM, deadalnix wrote:
Same argument Walter like to make about very rare failure
cases apply here.
1. rare as in programmers rarely create such a bug
2. rare as in being rare for an existing bug to show itself
I
On Sun, 19 May 2013 16:03:24 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/19/13 3:36 PM, deadalnix wrote:
I described a very usual null bug : something is set to null, then to a
specific value. It is assumed not to be null. In a specific case it is
null and everything
On 05/20/2013 01:39 AM, Andrei Alexandrescu wrote:
On 5/19/13 7:06 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 22:32:58 UTC, Andrei Alexandrescu wrote:
How was there a bug if everything was properly synchronized? You
either describe the matter with sufficient detail, or acknowledge the
On 05/20/2013 02:33 AM, deadalnix wrote:
On Monday, 20 May 2013 at 00:09:23 UTC, Walter Bright wrote:
On 5/19/2013 3:04 PM, deadalnix wrote:
Same argument Walter like to make about very rare failure cases apply
here.
1. rare as in programmers rarely create such a bug
2. rare as in being
Unfortunately this is currently not a bug.
T.init provides default initialized object image, and it *does not*
provide default constructed object. The difference is important.
That is already documented in lanugage reference.
http://dlang.org/property#init
Note: .init produces a default
On 5/19/2013 5:28 PM, deadalnix wrote:
The error lie in improper
initialization of p in the first place, which should never has been null. The
example looks dumb as this, you have to imagine the pattern hidden in thousands
of LOC.
I would find a design that declared a variable in one place,
On 5/19/2013 5:23 PM, John Colvin wrote:
On Sunday, 19 May 2013 at 20:45:39 UTC, Walter Bright wrote:
On 5/19/2013 1:03 PM, Maxim Fomin wrote:
I think there is difference between catching exception and saving
data which you have typed for some period and letting harware
check the exception for
On Monday, 20 May 2013 at 01:08:16 UTC, Walter Bright wrote:
On 5/19/2013 5:28 PM, deadalnix wrote:
The error lie in improper
initialization of p in the first place, which should never has
been null. The
example looks dumb as this, you have to imagine the pattern
hidden in thousands
of LOC.
On Monday, 20 May 2013 at 00:55:14 UTC, Kenji Hara wrote:
Unfortunately this is currently not a bug.
T.init provides default initialized object image, and it
*does not*
provide default constructed object. The difference is
important.
That is already documented in lanugage reference.
On Saturday, 18 May 2013 at 05:19:30 UTC, Maxim Fomin wrote:
On Saturday, 18 May 2013 at 02:34:46 UTC, Andrej Mitrovic wrote:
On 5/18/13, Timothee Cour thelastmamm...@gmail.com wrote:
S.init should be known at compile time by the spec.
But why is this needed?
It is needed in any place
On 5/17/13, Walter Bright wal...@digitalmars.com wrote:
I oppose this. D has a lot of nice features because of the
.init property.
Default constructors wreck that.
So much great feature like :
- null all over the place.
- Having NUllable and NonNullable in phobos. BTW, NonNullable is
On 5/18/2013 12:08 AM, deadalnix wrote:
On 5/17/13, Walter Bright wal...@digitalmars.com wrote:
I oppose this. D has a lot of nice features because of the .init property.
Default constructors wreck that.
So much great feature like :
- null all over the place.
- Having NUllable and
On Saturday, May 18, 2013 01:46:16 Igor Stepanov wrote:
When programmer see constructor, he think that it will be
evaluated each time when he create a new object.
This code will seem obvious for any C++ coder.
And this coder will be deceived.
If we'll add default constructor to structs,
1 - 100 of 142 matches
Mail list logo
