On 01/12/2013 09:24 PM, Alex Rønne Petersen wrote:
On 11-01-2013 19:15, Charles Hixson wrote:
I was looking for a way to create a weak reference to either a struct or
a class. I need to be able to use it to automatically generate an
active reference on access. (I intend to do this by rolling in
for a convenience.
Well, I'm not going to lie: You cannot implement weak references in D
any other way. The GC just isn't helpful enough.
The only way this code could break is if D ever gets a copying or
compacting GC. The chances of that happening, ever, are practically nil
because such GCs
On Saturday, 12 January 2013 at 04:41:00 UTC, Charles Hixson
wrote:
Thanks. That looks quite useful. OTOH, I don't see how the
pointer allows an item to be freed. You probably meant that
this was a framework to start development from.
Correct. To create an object if it wasn't there when
On Saturday, 12 January 2013 at 02:49:40 UTC, Jonathan M Davis
wrote:
That doesn't fly with the GC, because then you can have a
reference to memory
that's been freed - though I suppose that it could work if the
weak reference
were set to null when the normal reference was collected.
That
On Saturday, 12 January 2013 at 10:58:23 UTC, thedeemon wrote:
So the runtime is aware of weak pointers and clears them to
empty state when pointed value dies. I don't see yet how it
can be implemented in D without patching its GC.
There's that, but also what about what if the pointer wasn't
On 01/12/2013 03:27 AM, Era Scarecrow wrote:
On Saturday, 12 January 2013 at 10:58:23 UTC, thedeemon wrote:
So the runtime is aware of weak pointers and clears them to empty
state when pointed value dies. I don't see yet how it can be
implemented in D without patching its GC.
There's that,
On 01/12/2013 02:04 AM, Era Scarecrow wrote:
On Saturday, 12 January 2013 at 04:41:00 UTC, Charles Hixson wrote:
Thanks. That looks quite useful. OTOH, I don't see how the pointer
allows an item to be freed. You probably meant that this was a
framework to start development from.
Correct. To
On Sunday, 13 January 2013 at 00:37:07 UTC, Charles Hixson wrote:
P.S.: Perhaps you're thinking of unions with a combination of
floats and pointers in them. Legal, I think, but still a
really bad idea.
No; Unless you flag every relevant portion as pointer/non
pointer, then a float can get
On Sunday, 13 January 2013 at 00:56:59 UTC, Charles Hixson wrote:
I don't think reference counting would work for my purposes,
which is why I wanted a weak pointer. There will usually be
many live references at the time I need to release an item. If
I'd had weak pointers I could have made
On 11-01-2013 19:15, Charles Hixson wrote:
I was looking for a way to create a weak reference to either a struct or
a class. I need to be able to use it to automatically generate an
active reference on access. (I intend to do this by rolling in data
from a file.)
Any guidance as to where I
I was looking for a way to create a weak reference to either a struct or
a class. I need to be able to use it to automatically generate an
active reference on access. (I intend to do this by rolling in data
from a file.)
Any guidance as to where I should look?
On Friday, 11 January 2013 at 18:22:30 UTC, Charles Hixson wrote:
I was looking for a way to create a weak reference to either a
struct or a class. I need to be able to use it to
automatically generate an active reference on access. (I
intend to do this by rolling in data from a file.)
Any
On Friday, 11 January 2013 at 21:12:40 UTC, Era Scarecrow wrote:
I've tried making a weakPtr template function, however it
complains about a nested function call (perhaps cause it was
within a unittest); Shows the problem(s) on that side.
Honest question: How can you have a weak pointer in a
I had the impression in the original text you wanted to auto
allocate memory when accessing the field, not as described here.
Might be time to re-watch the remainder of the computer science
lectures.
On Friday, 11 January 2013 at 23:51:04 UTC, Nekroze wrote:
A weak reference to an object is
On Saturday, January 12, 2013 00:51:02 Nekroze wrote:
On Friday, 11 January 2013 at 22:07:45 UTC, monarch_dodra wrote:
Honest question: How can you have a weak pointer in a language
that is garbage collected?
I beleive the OP means something like pythons weakref
On 01/11/2013 01:12 PM, Era Scarecrow wrote:
On Friday, 11 January 2013 at 18:22:30 UTC, Charles Hixson wrote:
I was looking for a way to create a weak reference to either a struct
or a class. I need to be able to use it to automatically generate an
active reference on access. (I intend to do
void main()
{
void* x = a(b());
c();
while(goobledegook)
{
x = p();
d(x);
}
e(x); /+ Crash! x is null. +/
}
Where did x's null value come from? Not a. Not p; the while
loop happened to be never executed. To say b
On 10/07/2012 02:22 AM, David Piepgrass wrote:
void main()
{
void* x = a(b());
c();
while(goobledegook)
{
x = p();
d(x);
}
e(x); /+ Crash! x is null. +/
}
Where did x's null value come from? Not a. Not p; the while loop
happened to be never executed. To say b would be closer, but still
On Saturday, 6 October 2012 at 04:10:28 UTC, Chad J wrote:
On 10/05/2012 08:31 AM, Regan Heath wrote:
On Fri, 05 Oct 2012 05:19:13 +0100, Alex Burton
alexibureplacewithz...@gmail.com wrote:
On Saturday, 15 September 2012 at 17:51:39 UTC, Jonathan M
Davis wrote:
On Saturday, September 15, 2012
Franciszek Czekała:
Insistance on formal tools is a misunderstanding that leads to
design bloat and eventually failure (Ada).
D competes directly with C++ as Ada did before. Ada drowned
under the weight of its safety and so will D if it goes the
same route. The only thing needed now are
On 10/06/2012 10:18 AM, Franciszek Czekała h...@valentimex.com wrote:
Every function should define its interface, its contract
with the outside world. If a() function returns a pointer it is a part
of the contract whether it can be null.
The default should be it can't be null. Why would it be
On 10/06/2012 04:18 AM, Franciszek Czekała h...@valentimex.com wrote:
On Saturday, 6 October 2012 at 04:10:28 UTC, Chad J wrote:
I find this to be very suboptimal at the least.
This prevents null values from traveling up the stack, but still
allows them to move down (as return values) and
On 10/06/2012 04:18 AM, Franciszek Czekała h...@valentimex.com wrote:
B) The description of a() says the return value cannot be null. Then a()
should check its return value before returning or make otherwise sure it
is not null. If it returns null it is a bug. One of the infinite number
of
On Friday, 5 October 2012 at 04:50:18 UTC, Jonathan M Davis wrote:
On Friday, October 05, 2012 05:42:03 Alex Burton wrote:
I realise what is currently the case I am making an argument as
to why I this should be changed (at least for class references
in
D).
This was talking about C
On Fri, 05 Oct 2012 05:19:13 +0100, Alex Burton
alexibureplacewithz...@gmail.com wrote:
On Saturday, 15 September 2012 at 17:51:39 UTC, Jonathan M Davis wrote:
On Saturday, September 15, 2012 19:35:44 Alex Rønne Petersen wrote:
Out of curiosity: Why? How often does your code actually accept
Regan Heath:
That's a matter of opinion. I like to see null checks at the
top of a function or method, it makes it far more likely to be
safe and it means I can ignore the possibility of null from
then on - making the code much cleaner.
Even more clear/short/light is to not need such
On Friday, 5 October 2012 at 13:57:13 UTC, bearophile wrote:
void foo1(C1 c1, C2 c2)
in {
assert(c1 !is null);
assert(c2 !is null);
} body {
...
}
And in public library code, you can't even use assert. You have
to throw an error/exception. Runtime checks guaranteed even in
On Friday, October 05, 2012 08:45:31 Alex Burton wrote:
One is the language designer allowing null to be an acceptable
value for a pointer to an int.
As should be blatently obvious that null is not a pointer to an
int, but for historical reasons inherited from C (when people
were just happy
On 2012-13-05 20:10, Jonathan M Davis jmdavisp...@gmx.com wrote:
It would be a _huge_ design mistake for a systems language not to have
nullable pointers. Having non-nullable references or pointers in
addition to nullable ones might be useful, but not having nullable ones
at all would be
On Fri, Oct 5, 2012 at 11:13 AM, Jonathan M Davis jmdavisp...@gmx.comwrote:
You are going to find plenty of people who disagree quite strongly with
you.
There are times when having a type be non-nullable is very useful, but
there
are times when having a type be nullable is extremely useful.
On Friday, 5 October 2012 at 18:36:07 UTC, Simen Kjaeraas wrote:
Indeed. However, given both types, I would argue that
non-nullable by
default would go best with the D design guidelines - safe
before unsafe,
to be specific.
Clearly that would be the case, else we're tossing aside the
it to be nullable, you can
still make use of real pointers. Pointers can be converted to
references by implicitly do a runtime check if the pointer is
not null and references can be converted back to pointers.
I guess you had good reasons about choosing the nullable
version of D references. Explain
On 10/05/2012 08:31 AM, Regan Heath wrote:
On Fri, 05 Oct 2012 05:19:13 +0100, Alex Burton
alexibureplacewithz...@gmail.com wrote:
On Saturday, 15 September 2012 at 17:51:39 UTC, Jonathan M Davis wrote:
On Saturday, September 15, 2012 19:35:44 Alex Rønne Petersen wrote:
Out of curiosity:
On 10/03/2012 01:31 PM, Franciszek Czekała h...@valentimex.com wrote:
On Wednesday, 3 October 2012 at 16:33:15 UTC, Simen Kjaeraas wrote:
On 2012-10-03, 18:12, wrote:
They make sure you never pass null to a function that doesn't expect
null - I'd say that's a nice advantage.
No, it is
On Saturday, 15 September 2012 at 21:30:03 UTC, Walter Bright
wrote:
On 9/15/2012 5:39 AM, Henning Pohl wrote:
The way D is dealing with classes reminds me of pointers
because you can null
them. C++'s references cannot (of course you can do some nasty
casting).
Doing null references in C++
Timon Gehr:
To quote (loosely) Mr. Walter Bright from another discussion:
how many
current bugs in dmd are related to default null references?
More than zero.
A 0 frequency of bugs caused by something can't be enough to
justify a language feature. You need a high enough frequency :-)
On 10/04/2012 01:38 PM, bearophile wrote:
Timon Gehr:
To quote (loosely) Mr. Walter Bright from another discussion: how many
current bugs in dmd are related to default null references?
More than zero.
A 0 frequency of bugs caused by something can't be enough to justify a
language feature.
On Thursday, October 04, 2012 13:14:00 Alex Burton, @gmail.com wrote:
On Saturday, 15 September 2012 at 21:30:03 UTC, Walter Bright
wrote:
On 9/15/2012 5:39 AM, Henning Pohl wrote:
The way D is dealing with classes reminds me of pointers
because you can null
them. C++'s references
and the crash.
I realise what is currently the case I am making an argument as
to why I this should be changed (at least for class references in
D).
In the same way this should fail:
Class A
{
}
A a;
And why would this fail? It's also perfectly legal.
I realise that this is currently legal, I
On Wednesday, 3 October 2012 at 17:37:14 UTC, Franciszek Czekała
wrote:
On Wednesday, 3 October 2012 at 16:33:15 UTC, Simen Kjaeraas
wrote:
On 2012-10-03, 18:12, wrote:
They make sure you never pass null to a function that doesn't
expect null - I'd say that's a nice advantage.
However
On Saturday, 15 September 2012 at 17:51:39 UTC, Jonathan M Davis
wrote:
On Saturday, September 15, 2012 19:35:44 Alex Rønne Petersen
wrote:
Out of curiosity: Why? How often does your code actually
accept null as
a valid state of a class reference?
I have no idea. I know that it's a
On Friday, October 05, 2012 05:42:03 Alex Burton wrote:
I realise what is currently the case I am making an argument as
to why I this should be changed (at least for class references in
D).
This was talking about C++ references, not D, giving an example of how they
can be null even though
On Mon, Sep 24, 2012 at 5:23 AM, Regan Heath re...@netmail.co.nz wrote:
What I've noticed looking at Java code written by others is that null as a
possible state is ignored by the vast bulk of the code, which is completely
the opposite when reviewing C/C++ code where null is checked for and
On Saturday, 15 September 2012 at 17:12:23 UTC, Jonathan M Davis
wrote:
On Saturday, September 15, 2012 15:24:27 Henning Pohl wrote:
On Saturday, 15 September 2012 at 12:49:23 UTC, Russel Winder
wrote:
On Sat, 2012-09-15 at 14:44 +0200, Alex Rønne Petersen
wrote:
[…]
Anyway, it's too
On Wednesday, 3 October 2012 at 08:11:32 UTC, Franciszek Czekała
wrote:
On Saturday, 15 September 2012 at 17:12:23 UTC, Jonathan M
Davis wrote:
On Saturday, September 15, 2012 15:24:27 Henning Pohl wrote:
On Saturday, 15 September 2012 at 12:49:23 UTC, Russel Winder
wrote:
On Sat, 2012-09-15
On Wednesday, 3 October 2012 at 08:11:32 UTC, Franciszek Czekała
wrote:
Agreed. Nullable types are a feature not a bug. There is no
need to change it. Bugs occur when you do not know the language
rules and make assumptions instead. This can happen whith any
language and any rules. As to an
On Wednesday, 3 October 2012 at 10:41:34 UTC, Henning Pohl wrote:
On Wednesday, 3 October 2012 at 08:11:32 UTC, Franciszek
Czekała wrote:
Agreed. Nullable types are a feature not a bug. There is no
need to change it. Bugs occur when you do not know the
language rules and make assumptions
On Wednesday, 3 October 2012 at 10:41:34 UTC, Henning Pohl wrote:
On Wednesday, 3 October 2012 at 08:11:32 UTC, Franciszek
Czekała wrote:
Agreed. Nullable types are a feature not a bug. There is no
need to change it. Bugs occur when you do not know the
language rules and make assumptions
On 2012-56-03 14:10, wrote:
The need of using null: Every type needs a default value.
Good gods, are we not done with this strawman yet?
No, not all types need a default value. In fact, for some types, it is
much better that they don't.
Consider my board example: with null standing for
On Wednesday, 3 October 2012 at 12:56:41 UTC, Franciszek Czekała
wrote:
The need of using null: Every type needs a default value.
This is just plain wrong. There even is a feature in D which
solely exists for the purpose of allowing struct types _not_ to
have a default value (@disable this)…
On Wednesday, 3 October 2012 at 14:49:36 UTC, Simen Kjaeraas
wrote:
On 2012-56-03 14:10, wrote:
The need of using null: Every type needs a default value.
Good gods, are we not done with this strawman yet?
No, not all types need a default value. In fact, for some
types, it is
much better
On 2012-10-03, 18:12, wrote:
As my comments indicated : the presence of a value does not guarantee a
valid value by itself. The C++ declaration int n; introduces a value,
good luck using it.
Which is why non-nullable references must not allow the programmer to
declare them without also
On Wednesday, 3 October 2012 at 16:11:53 UTC, Franciszek Czekała
wrote:
As my comments indicated : the presence of a value does not
guarantee a valid value by itself. The C++ declaration int n;
introduces a value, good luck using it.
auto c = new Class();
Tell me, does c contain an invalid
On Wednesday, 3 October 2012 at 16:36:15 UTC, Henning Pohl wrote:
Just put something like a questionmark behind the reference
type to indicate that it's nullable.
...
Not really. It's all about one question mark for example.
How much code would be broken by moving nullable references from
On Wednesday, 3 October 2012 at 16:58:52 UTC, Maxim Fomin wrote:
How much code would be broken by moving nullable references
from current state to question mark notation?
That's another question :]
I expect that non-nullable class objects (called references
here) addition (if there is no
On Wednesday, 3 October 2012 at 16:58:52 UTC, Maxim Fomin wrote:
How much code would be broken by moving nullable references
from current state to question mark notation?
That's another question :]
I expect that non-nullable class objects (called references
here) addition (if there is no
On Wednesday, 3 October 2012 at 16:58:52 UTC, Maxim Fomin wrote:
How much code would be broken by moving nullable references
from current state to question mark notation?
That's another question :]
I expect that non-nullable class objects (called references
here) addition (if there is no
On Wednesday, 3 October 2012 at 16:33:15 UTC, Simen Kjaeraas
wrote:
On 2012-10-03, 18:12, wrote:
They make sure you never pass null to a function that doesn't
expect null - I'd say that's a nice advantage.
No, it is meaningless. If you have a class which is supposed to
hold a prime
Franciszek Czekała:
I maintain that this non-null advantage does not warrant to
make the language more complicated even by a tiny bit. It is
dwarfed by normal considerations related to program correctness.
Surely there are more important things to care about. But a
non-null system has right
On Wednesday, 3 October 2012 at 17:37:14 UTC, Franciszek Czekała
wrote:
No, it is meaningless. If you have a class which is supposed to
hold a prime number and you pass it to a function are you going
to check each time that the value is indeed prime? That would
kill the efficiency of your
On Wednesday, 3 October 2012 at 18:12:51 UTC, Henning Pohl wrote:
class PrimeNumber : Number {
this(int i) {
// Check whether i is a prime number or not...
super(i);
}
}
This is a good example in that validity of the data can be
checked from inside the class
On 2012-10-03, 19:31, wrote:
On Wednesday, 3 October 2012 at 16:33:15 UTC, Simen Kjaeraas wrote:
On 2012-10-03, 18:12, wrote:
They make sure you never pass null to a function that doesn't expect
null - I'd say that's a nice advantage.
No, it is meaningless. If you have a class which
On 10/03/2012 07:31 PM, Franciszek Czekała h...@valentimex.com wrote:
...
To quote (loosely) Mr. Walter Bright from another discussion: how many
current bugs in dmd are related to default null references?
More than zero.
On 10/03/2012 06:59 PM, Maxim Fomin wrote:
On Wednesday, 3 October 2012 at 16:36:15 UTC, Henning Pohl wrote:
Just put something like a questionmark behind the reference type to
indicate that it's nullable.
...
Not really. It's all about one question mark for example.
How much code would be
On Wednesday, October 03, 2012 18:14:46 David Nadlinger wrote:
On Wednesday, 3 October 2012 at 12:56:41 UTC, Franciszek Czekała
wrote:
The need of using null: Every type needs a default value.
This is just plain wrong. There even is a feature in D which
solely exists for the purpose of
On Tuesday, 18 September 2012 at 19:30:24 UTC, Simen Kjaeraas
wrote:
On Tue, 18 Sep 2012 16:56:31 +0200, Mehrdad
wfunct...@hotmail.com wrote:
On Saturday, 15 September 2012 at 23:28:36 UTC, Walter Bright
wrote:
I wouldn't worry about it. I suspect that most C++
programmers think that
On Tuesday, 25 September 2012 at 09:00:39 UTC, Mehrdad wrote:
What does this have to do with const?
...
Not only is it irrelevant, it's also wrong:
It's harder to do that in C++ than in D.
My bad, it's not irrelevant, I misunderstood your reasoning.
It's still wrong though. :)
On Sun, 16 Sep 2012 23:46:34 +0100, deadalnix deadal...@gmail.com wrote:
Le 15/09/2012 19:13, Jonathan M Davis a écrit :
On Saturday, September 15, 2012 15:24:27 Henning Pohl wrote:
On Saturday, 15 September 2012 at 12:49:23 UTC, Russel Winder
wrote:
On Sat, 2012-09-15 at 14:44 +0200, Alex
Regan Heath:
In fact, I am often annoyed that 'int' doesn't have an
equivalent value, and instead I have to invent a magic number
and ensure it's never a possible valid value.
Try to start using Nullable of Phobos:
http://dlang.org/phobos/std_typecons.html#Nullable
Bye,
bearophile
On Mon, 24 Sep 2012 13:30:29 +0100, bearophile bearophileh...@lycos.com
wrote:
Regan Heath:
In fact, I am often annoyed that 'int' doesn't have an equivalent
value, and instead I have to invent a magic number and ensure it's
never a possible valid value.
Try to start using Nullable of
On Mon, 24 Sep 2012 14:38:56 +0200, Regan Heath re...@netmail.co.nz
wrote:
On Mon, 24 Sep 2012 13:30:29 +0100, bearophile
bearophileh...@lycos.com wrote:
Regan Heath:
In fact, I am often annoyed that 'int' doesn't have an equivalent
value, and instead I have to invent a magic number
On Saturday, 15 September 2012 at 23:28:36 UTC, Walter Bright
wrote:
I wouldn't worry about it. I suspect that most C++ programmers
think that references cannot be null.
Yeah, they can't be null _legally_.
Kind of like how in D you can't strip away const _legally_.
But the compiler doesn't
On Tue, 18 Sep 2012 16:56:31 +0200, Mehrdad wfunct...@hotmail.com wrote:
On Saturday, 15 September 2012 at 23:28:36 UTC, Walter Bright wrote:
I wouldn't worry about it. I suspect that most C++ programmers think
that references cannot be null.
Yeah, they can't be null _legally_.
Kind of
On Monday, 17 September 2012 at 00:22:52 UTC, Jonathan M Davis
wrote:
On Monday, September 17, 2012 00:43:50 deadalnix wrote:
It shouldn't be that hard to create a Nullable!T template.
We have one, and it would be wasteful to use that for
references or pointers
when they're naturally
Le 17/09/2012 02:23, Jonathan M Davis a écrit :
On Monday, September 17, 2012 00:43:50 deadalnix wrote:
It shouldn't be that hard to create a Nullable!T template.
We have one, and it would be wasteful to use that for references or pointers
when they're naturally nullable (though you're more
On Monday, September 17, 2012 12:52:52 deadalnix wrote:
Le 17/09/2012 02:23, Jonathan M Davis a écrit :
Regardless, the solution at this point is going to be to add
std.typecons.NonNullable. It would be in there already, but the pull
request with it needed more work, and it hasn't been
On Monday, September 17, 2012 13:00:15 deadalnix wrote:
Don't take this wrong, I do know that this is a major breakage, and
would arm the language if applied in any short term manner. Still,
acknowledging error that have been made is usefull.
Not everyone agrees that an error _was_ made.
On 9/17/12 6:52 AM, deadalnix wrote:
Regardless, the solution at this point is going to be to add
std.typecons.NonNullable. It would be in there already, but the pull
request
with it needed more work, and it hasn't been resubmitted yet.
I don't think this is implementable as a lib in a
On Mon, 2012-09-17 at 09:12 -0400, Andrei Alexandrescu wrote:
On 9/17/12 6:52 AM, deadalnix wrote:
Regardless, the solution at this point is going to be to add
std.typecons.NonNullable. It would be in there already, but the pull
request
with it needed more work, and it hasn't been
On 09/17/2012 03:33 AM, Jonathan M Davis wrote:
On Monday, September 17, 2012 03:27:10 Timon Gehr wrote:
On 09/17/2012 02:23 AM, Jonathan M Davis wrote:
... That might make sense for an int, since
it can't be null, but pointers and references _can_ be and are in every
type system that I've
On Mon, 2012-09-17 at 15:49 +0200, Timon Gehr wrote:
[…]
In effect, everything is a non-null reference to mutable, but as
mutation is constrained rather specifically, it is possible to reason
about the behaviour of Haskell programs on a higher level of
abstraction.
let fib n = if n2 then
On 17-09-2012 15:12, Andrei Alexandrescu wrote:
On 9/17/12 6:52 AM, deadalnix wrote:
Regardless, the solution at this point is going to be to add
std.typecons.NonNullable. It would be in there already, but the pull
request
with it needed more work, and it hasn't been resubmitted yet.
I don't
On 09/17/2012 03:56 PM, Russel Winder wrote:
On Mon, 2012-09-17 at 15:49 +0200, Timon Gehr wrote:
[…]
In effect, everything is a non-null reference to mutable, but as
mutation is constrained rather specifically, it is possible to reason
about the behaviour of Haskell programs on a higher level
On Mon, 17 Sep 2012 16:28:46 +0200, Alex Rønne Petersen a...@lycus.org
wrote:
On 17-09-2012 15:12, Andrei Alexandrescu wrote:
On 9/17/12 6:52 AM, deadalnix wrote:
Regardless, the solution at this point is going to be to add
std.typecons.NonNullable. It would be in there already, but the
On Monday, 17 September 2012 at 13:43:21 UTC, Russel Winder wrote:
Somewhat hypocritically as I cannot volunteer myself just
now… just
because Walter didn't get round to it, doesn't mean it can't be
done.
People who want the feature should find a way of creating the
resource
to make it happen.
On 9/17/12 9:43 AM, Russel Winder wrote:
Somewhat hypocritically as I cannot volunteer myself just now… just
because Walter didn't get round to it, doesn't mean it can't be done.
People who want the feature should find a way of creating the resource
to make it happen. Four ways: volunteer to do
On 9/17/12 10:28 AM, Alex Rønne Petersen wrote:
On 17-09-2012 15:12, Andrei Alexandrescu wrote:
On 9/17/12 6:52 AM, deadalnix wrote:
Regardless, the solution at this point is going to be to add
std.typecons.NonNullable. It would be in there already, but the pull
request
with it needed more
Le 17/09/2012 15:12, Andrei Alexandrescu a écrit :
On 9/17/12 6:52 AM, deadalnix wrote:
Regardless, the solution at this point is going to be to add
std.typecons.NonNullable. It would be in there already, but the pull
request
with it needed more work, and it hasn't been resubmitted yet.
I
On 9/17/12 12:41 PM, deadalnix wrote:
Le 17/09/2012 15:12, Andrei Alexandrescu a écrit :
On 9/17/12 6:52 AM, deadalnix wrote:
Regardless, the solution at this point is going to be to add
std.typecons.NonNullable. It would be in there already, but the pull
request
with it needed more work, and
Andrei Alexandrescu:
Our position is that NonNull is only one of several instances
of a much more general pattern, which can be addressed with
@disable once it is properly tracked inside constructors.
It's an iterative process: some people invent a feature and put
in a language, others find
On 9/17/12 1:15 PM, bearophile wrote:
Andrei Alexandrescu:
Our position is that NonNull is only one of several instances of a
much more general pattern, which can be addressed with @disable once
it is properly tracked inside constructors.
It's an iterative process: some people invent a
Le 17/09/2012 13:07, Jonathan M Davis a écrit :
On Monday, September 17, 2012 13:00:15 deadalnix wrote:
Don't take this wrong, I do know that this is a major breakage, and
would arm the language if applied in any short term manner. Still,
acknowledging error that have been made is usefull.
Le 17/09/2012 19:07, Andrei Alexandrescu a écrit :
On 9/17/12 12:41 PM, deadalnix wrote:
Le 17/09/2012 15:12, Andrei Alexandrescu a écrit :
On 9/17/12 6:52 AM, deadalnix wrote:
Regardless, the solution at this point is going to be to add
std.typecons.NonNullable. It would be in there already,
On Sat, 15 Sep 2012 20:06:01 +0200, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Saturday, September 15, 2012 19:57:03 Henning Pohl wrote:
On Saturday, 15 September 2012 at 17:12:23 UTC, Jonathan M Davis
wrote:
Of course people use it. Having nullable types is _highly_
useful. It would
On Saturday, 15 September 2012 at 23:34:44 UTC, Jonathan M Davis
wrote:
On Saturday, September 15, 2012 16:29:32 Walter Bright wrote:
I wouldn't worry about it. I suspect that most C++ programmers
think that
references cannot be null. C++ is a complex language, and
invites
assumptions about
On 2012-09-15 23:30, Walter Bright wrote:
Doing null references in C++ is simple:
int *p = NULL;
int r = *p;
r = 3; // crash
Won't that crash at the first assignment of r, since you dereferencing
a null pointer?.
--
/Jacob Carlborg
On 16-09-2012 13:33, Jacob Carlborg wrote:
On 2012-09-15 23:30, Walter Bright wrote:
Doing null references in C++ is simple:
int *p = NULL;
int r = *p;
r = 3; // crash
Won't that crash at the first assignment of r, since you dereferencing
a null pointer?.
Nope, since in this context
On 2012-09-16 13:47, Alex Rønne Petersen wrote:
Nope, since in this context you're assigning it to an int. So it really
just means r = p if you assume that references are just pointers
(which they are in most implementations).
Ah, I didn't think of that.
--
/Jacob Carlborg
to do no explicit runtime checks.
Are you using reference runtime checks in your current code?
D has null references, so I use them. I would prefer option types, but
they are too verbose in D as things stand.
It shouldn't be that hard to create a Nullable!T template.
Le 15/09/2012 19:13, Jonathan M Davis a écrit :
On Saturday, September 15, 2012 15:24:27 Henning Pohl wrote:
On Saturday, 15 September 2012 at 12:49:23 UTC, Russel Winder
wrote:
On Sat, 2012-09-15 at 14:44 +0200, Alex Rønne Petersen wrote:
[…]
Anyway, it's too late to change it now.
I
1 - 100 of 141 matches
Mail list logo
