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
On Saturday, 15 September 2012 at 12:38:53 UTC, 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). So you can be sure to have a
valid well-defined object. But then there is
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
On Thursday, 4 October 2012 at 17:55:45 UTC, Jonathan M Davis
wrote:
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
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
Le 15/09/2012 16:23, Alex Rønne Petersen a écrit :
On 15-09-2012 15:24, 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 disagree. There are
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
On Sunday, September 16, 2012 12:08:52 Peter Alexander wrote:
My favourite C++ wtf:
struct Foo
{
template int x, int y int fun(bool c) { return c ? x : y; }
};
struct Bar
{
int fun;
};
template typename T
int madness()
{
return T().fun1, 2(true);
}
The WTF:
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 or less forced to if you
want a truly nullable
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 ever used.
...
You have claimed multiple times to have used Haskell.
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 ever used.
...
You have claimed multiple
On 15-09-2012 14:39, 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). So you can be sure to have a valid well-defined object. But
then there is always the ownership problem
On Sat, 2012-09-15 at 14:44 +0200, Alex Rønne Petersen wrote:
[…]
Anyway, it's too late to change it now.
I disagree. There are always opportunities to make changes to things,
you just have manage things carefully.
--
Russel.
That is the one thing I miss also.
The solution until now is to use a wrapper struct around a class,
but that is _very_ annoying and a good language should have
something on their own.
But it is right, for D2 this mistake is going to long as you can
change it so soon.
But maybe a Syntax like
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 disagree. There are always opportunities to make changes to
things,
you just have manage things carefully.
I
On Saturday, 15 September 2012 at 12:38:53 UTC, 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). So you can be sure to have a
valid well-defined object. But then there is
On Saturday, 15 September 2012 at 12:43:22 UTC, Alex Rønne
Petersen wrote:
But this being said, I agree that references being nullable by
default is hurtful. It allows any object reference to have an
invalid state even though in 99% of cases, that doesn't make
sense. It's a giant hole in the
On Sat, 15 Sep 2012 15:32:35 +0200, Maxim Fomin ma...@maxim-fomin.ru
wrote:
On Saturday, 15 September 2012 at 12:38:53 UTC, 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
On Saturday, 15 September 2012 at 13:36:00 UTC, Maxim Fomin wrote:
On Saturday, 15 September 2012 at 12:43:22 UTC, Alex Rønne
Petersen wrote:
But this being said, I agree that references being nullable by
default is hurtful. It allows any object reference to have an
invalid state even though
On Saturday, 15 September 2012 at 13:49:02 UTC, Simen Kjaeraas
wrote:
void foo(ref S s); // cannot pass null pointer S* or null -
always there
void bar( ref int n ) {
n = 3;
}
void main( ) {
int* p = null;
bar( *p );
}
Good luck.
Of course, it's not that obvious in production
On Sat, 15 Sep 2012 14:39:49 +0200, Henning Pohl henn...@still-hidden.de
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). So you can be sure to have a valid well-defined object. But
On Sat, 15 Sep 2012 16:06:38 +0200, Maxim Fomin ma...@maxim-fomin.ru
wrote:
On Saturday, 15 September 2012 at 13:49:02 UTC, Simen Kjaeraas wrote:
void foo(ref S s); // cannot pass null pointer S* or null - always
there
void bar( ref int n ) {
n = 3;
}
void main( ) {
int* p =
On 15-09-2012 14:50, 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 disagree. There are always opportunities to make changes to things,
you just have manage things carefully.
You can't really do this
1 - 100 of 124 matches
Mail list logo
