www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Proposal : allocations made easier with non nullable types.

reply Alex Burton <alexibu mac.com> writes:
I think it makes no sense to have nullable pointers in a high level language
like D.

In D :

X x = new X;
This is a bit redundant, if we take away the ability to write X x; to mean X x
= 0; then we can have X x; mean X x = new X;
If the class has a ctor then we can write X x(32); instead of X x = new X(32);
Only when the types of the pointer and class are different do we need to write
X x = new Y;
We can do this syntactically in D because classes cannot be instantiated on the
stack (unless scope is used, which I have found a bit pointless, as members are
not scope so no deterministic dtor)

This makes the code much less verbose and allows code to change from X being a
struct to X being a class without having to go around and change all the X x;
to X = new X;

As I said in the nullable types thread:
Passing 0 or 0x012345A or anything else that is not a pointer to an instance of
X to a variable declared as X x is the same as mixing in a bicycle when a
recipe asks for a cup of olive oil.

There are much better, and less error prone ways to write code in a high level
language than allowing null pointers.

Alex
Feb 09 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 09 Feb 2009 13:48:39 +0300, Alex Burton <alexibu mac.com> wrote:

 I think it makes no sense to have nullable pointers in a high level  
 language like D.

 In D :

 X x = new X;
 This is a bit redundant, if we take away the ability to write X x; to  
 mean X x = 0; then we can have X x; mean X x = new X;
 If the class has a ctor then we can write X x(32); instead of X x = new  
 X(32);
 Only when the types of the pointer and class are different do we need to  
 write X x = new Y;
 We can do this syntactically in D because classes cannot be instantiated  
 on the stack (unless scope is used, which I have found a bit pointless,  
 as members are not scope so no deterministic dtor)

 This makes the code much less verbose and allows code to change from X  
 being a struct to X being a class without having to go around and change  
 all the X x; to X = new X;

 As I said in the nullable types thread:
 Passing 0 or 0x012345A or anything else that is not a pointer to an  
 instance of X to a variable declared as X x is the same as mixing in a  
 bicycle when a recipe asks for a cup of olive oil.

 There are much better, and less error prone ways to write code in a high  
 level language than allowing null pointers.

 Alex

I remember Andrei has showed interest in unification of the way value and reference types are instantiated: Foo foo(arg1, arg2); // valid instance, be it reference of value type Bar bar; // same here (default ctor is called) and ditch 'new' keyword altogether. Note that you can't delete non-nullable reference so 'delete' keyword is not needed, too (use scope instead). Nullable types, however, may be recycled with e.g. GC.delete(foo); That said, I'd like to see an experimental version of DMD with these featured enabled. It looks nice at first glance, but time and experience is needed to get better understanding of this.
Feb 09 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Mon, 09 Feb 2009 13:48:39 +0300, Alex Burton <alexibu mac.com> wrote:
 
 I think it makes no sense to have nullable pointers in a high level 
 language like D.

 In D :

 X x = new X;
 This is a bit redundant, if we take away the ability to write X x; to 
 mean X x = 0; then we can have X x; mean X x = new X;
 If the class has a ctor then we can write X x(32); instead of X x = 
 new X(32);
 Only when the types of the pointer and class are different do we need 
 to write X x = new Y;
 We can do this syntactically in D because classes cannot be 
 instantiated on the stack (unless scope is used, which I have found a 
 bit pointless, as members are not scope so no deterministic dtor)

 This makes the code much less verbose and allows code to change from X 
 being a struct to X being a class without having to go around and 
 change all the X x; to X = new X;

 As I said in the nullable types thread:
 Passing 0 or 0x012345A or anything else that is not a pointer to an 
 instance of X to a variable declared as X x is the same as mixing in a 
 bicycle when a recipe asks for a cup of olive oil.

 There are much better, and less error prone ways to write code in a 
 high level language than allowing null pointers.

 Alex

I remember Andrei has showed interest in unification of the way value and reference types are instantiated: Foo foo(arg1, arg2); // valid instance, be it reference of value type Bar bar; // same here (default ctor is called) and ditch 'new' keyword altogether.

That would be nice but Walter says he dislikes a dynamic allocation going under the covers.
 Note that you can't delete 
 non-nullable reference so 'delete' keyword is not needed, too (use scope 
 instead). Nullable types, however, may be recycled with e.g. 
 GC.delete(foo);

Delete-ing either non- or yes-nullable references is just as dangerous. IMHO the delete facility of the GC should be eliminated. (Long story.) Andrei
Feb 09 2009
parent reply Denis Koroskin <2korden gmail.com> writes:
Andrei Alexandrescu Wrote:

 Denis Koroskin wrote:
 On Mon, 09 Feb 2009 13:48:39 +0300, Alex Burton <alexibu mac.com> wrote:
 
 I think it makes no sense to have nullable pointers in a high level 
 language like D.

 In D :

 X x = new X;
 This is a bit redundant, if we take away the ability to write X x; to 
 mean X x = 0; then we can have X x; mean X x = new X;
 If the class has a ctor then we can write X x(32); instead of X x = 
 new X(32);
 Only when the types of the pointer and class are different do we need 
 to write X x = new Y;
 We can do this syntactically in D because classes cannot be 
 instantiated on the stack (unless scope is used, which I have found a 
 bit pointless, as members are not scope so no deterministic dtor)

 This makes the code much less verbose and allows code to change from X 
 being a struct to X being a class without having to go around and 
 change all the X x; to X = new X;

 As I said in the nullable types thread:
 Passing 0 or 0x012345A or anything else that is not a pointer to an 
 instance of X to a variable declared as X x is the same as mixing in a 
 bicycle when a recipe asks for a cup of olive oil.

 There are much better, and less error prone ways to write code in a 
 high level language than allowing null pointers.

 Alex

I remember Andrei has showed interest in unification of the way value and reference types are instantiated: Foo foo(arg1, arg2); // valid instance, be it reference of value type Bar bar; // same here (default ctor is called) and ditch 'new' keyword altogether.

That would be nice but Walter says he dislikes a dynamic allocation going under the covers.

How about dynamic closures? It's way much harder to /properly/ determine whether a closure allocates that to determine if Foo foo; allocates But it reduces syntax complexity (by removing one syntax construct) and make structs and classes a little bit more intechangeble, which is a plus, I think.
 Note that you can't delete 
 non-nullable reference so 'delete' keyword is not needed, too (use scope 
 instead). Nullable types, however, may be recycled with e.g. 
 GC.delete(foo);

Delete-ing either non- or yes-nullable references is just as dangerous. IMHO the delete facility of the GC should be eliminated. (Long story.)

I competely agree. Don't remember last time I used delete in D.
 
 Andrei

Feb 09 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Denis Koroskin wrote:
 Andrei Alexandrescu Wrote:
 
 Denis Koroskin wrote:
 On Mon, 09 Feb 2009 13:48:39 +0300, Alex Burton <alexibu mac.com> wrote:

 I think it makes no sense to have nullable pointers in a high level 
 language like D.

 In D :

 X x = new X;
 This is a bit redundant, if we take away the ability to write X x; to 
 mean X x = 0; then we can have X x; mean X x = new X;
 If the class has a ctor then we can write X x(32); instead of X x = 
 new X(32);
 Only when the types of the pointer and class are different do we need 
 to write X x = new Y;
 We can do this syntactically in D because classes cannot be 
 instantiated on the stack (unless scope is used, which I have found a 
 bit pointless, as members are not scope so no deterministic dtor)

 This makes the code much less verbose and allows code to change from X 
 being a struct to X being a class without having to go around and 
 change all the X x; to X = new X;

 As I said in the nullable types thread:
 Passing 0 or 0x012345A or anything else that is not a pointer to an 
 instance of X to a variable declared as X x is the same as mixing in a 
 bicycle when a recipe asks for a cup of olive oil.

 There are much better, and less error prone ways to write code in a 
 high level language than allowing null pointers.

 Alex

and reference types are instantiated: Foo foo(arg1, arg2); // valid instance, be it reference of value type Bar bar; // same here (default ctor is called) and ditch 'new' keyword altogether.

going under the covers.

How about dynamic closures? It's way much harder to /properly/ determine whether a closure allocates that to determine if Foo foo; allocates But it reduces syntax complexity (by removing one syntax construct) and make structs and classes a little bit more intechangeble, which is a plus, I think.
 Note that you can't delete 
 non-nullable reference so 'delete' keyword is not needed, too (use scope 
 instead). Nullable types, however, may be recycled with e.g. 
 GC.delete(foo);

IMHO the delete facility of the GC should be eliminated. (Long story.)

I competely agree. Don't remember last time I used delete in D.
 Andrei


I've used it for managing very large chunks of memory that I don't want hanging around. Access to this memory is generally mediated by small proxy object using reference counting so I know when it's OK to nuke that big chunk. GC is wonderful, but there are times where you just can't trust it. -- Daniel
Feb 09 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Daniel Keep wrote:
 
 Denis Koroskin wrote:
 Andrei Alexandrescu Wrote:

 Denis Koroskin wrote:
 On Mon, 09 Feb 2009 13:48:39 +0300, Alex Burton <alexibu mac.com> wrote:

 I think it makes no sense to have nullable pointers in a high level 
 language like D.

 In D :

 X x = new X;
 This is a bit redundant, if we take away the ability to write X x; to 
 mean X x = 0; then we can have X x; mean X x = new X;
 If the class has a ctor then we can write X x(32); instead of X x = 
 new X(32);
 Only when the types of the pointer and class are different do we need 
 to write X x = new Y;
 We can do this syntactically in D because classes cannot be 
 instantiated on the stack (unless scope is used, which I have found a 
 bit pointless, as members are not scope so no deterministic dtor)

 This makes the code much less verbose and allows code to change from X 
 being a struct to X being a class without having to go around and 
 change all the X x; to X = new X;

 As I said in the nullable types thread:
 Passing 0 or 0x012345A or anything else that is not a pointer to an 
 instance of X to a variable declared as X x is the same as mixing in a 
 bicycle when a recipe asks for a cup of olive oil.

 There are much better, and less error prone ways to write code in a 
 high level language than allowing null pointers.

 Alex

and reference types are instantiated: Foo foo(arg1, arg2); // valid instance, be it reference of value type Bar bar; // same here (default ctor is called) and ditch 'new' keyword altogether.

going under the covers.

 Note that you can't delete 
 non-nullable reference so 'delete' keyword is not needed, too (use scope 
 instead). Nullable types, however, may be recycled with e.g. 
 GC.delete(foo);

IMHO the delete facility of the GC should be eliminated. (Long story.)

 Andrei


I've used it for managing very large chunks of memory that I don't want hanging around. Access to this memory is generally mediated by small proxy object using reference counting so I know when it's OK to nuke that big chunk. GC is wonderful, but there are times where you just can't trust it. -- Daniel

Sure. My suggested framework is one in which you'd use malloc for those allocations. Then you can free. But plopping delete in the midst of a GC system... that's just uncalled for. Andrei
Feb 09 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Daniel Keep wrote:
 Denis Koroskin wrote:
 Andrei Alexandrescu Wrote:

 Denis Koroskin wrote:
 On Mon, 09 Feb 2009 13:48:39 +0300, Alex Burton <alexibu mac.com> wrote:

 I think it makes no sense to have nullable pointers in a high level
 language like D.

 In D :

 X x = new X;
 This is a bit redundant, if we take away the ability to write X x; to
 mean X x = 0; then we can have X x; mean X x = new X;
 If the class has a ctor then we can write X x(32); instead of X x =
 new X(32);
 Only when the types of the pointer and class are different do we need
 to write X x = new Y;
 We can do this syntactically in D because classes cannot be
 instantiated on the stack (unless scope is used, which I have found a
 bit pointless, as members are not scope so no deterministic dtor)

 This makes the code much less verbose and allows code to change from X
 being a struct to X being a class without having to go around and
 change all the X x; to X = new X;

 As I said in the nullable types thread:
 Passing 0 or 0x012345A or anything else that is not a pointer to an
 instance of X to a variable declared as X x is the same as mixing in a
 bicycle when a recipe asks for a cup of olive oil.

 There are much better, and less error prone ways to write code in a
 high level language than allowing null pointers.

 Alex

and reference types are instantiated: Foo foo(arg1, arg2); // valid instance, be it reference of value type Bar bar; // same here (default ctor is called) and ditch 'new' keyword altogether.

going under the covers.




syntax complexity (by removing one syntax construct) and make structs and classes a little bit more intechangeble, which is a plus, I think.
 Note that you can't delete
 non-nullable reference so 'delete' keyword is not needed, too (use scope
 instead). Nullable types, however, may be recycled with e.g.
 GC.delete(foo);

IMHO the delete facility of the GC should be eliminated. (Long story.)

 Andrei


I've used it for managing very large chunks of memory that I don't want hanging around. Access to this memory is generally mediated by small proxy object using reference counting so I know when it's OK to nuke that big chunk. GC is wonderful, but there are times where you just can't trust it. -- Daniel

allocations. Then you can free. But plopping delete in the midst of a GC system... that's just uncalled for. Andrei

But then, you can't delete, for example, builtin arrays. Furthermore, if you use C's malloc/free, you have to be really anal about making sure all code paths free the memory. With the ability to manually free GC managed memory, it becomes ok to miss an infrequently taken code path, like an exception, because it's just a performance optimization. Lastly, using multiple heaps like this seems kind of inefficient. There could be tons of free space on the GC heap, and you'd still be allocating on the C heap. I think it's fine to remove the delete keyword, but at least keep the GC.free library function.
Feb 09 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
dsimcha wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Sure. My suggested framework is one in which you'd use malloc for those
 allocations. Then you can free. But plopping delete in the midst of a GC
 system... that's just uncalled for.
 Andrei

But then, you can't delete, for example, builtin arrays.

You oughtn't.
 Furthermore, if you use
 C's malloc/free, you have to be really anal about making sure all code paths
free
 the memory.

I agree. But the underlying idea is that those places are few and far apart.
 With the ability to manually free GC managed memory, it becomes ok to
 miss an infrequently taken code path, like an exception, because it's just a
 performance optimization.

The problem is, many (most?) GCs don't support manual deletion. That's a quirk rather endemic to D's implementation. Relying on it is not wise because other allocators will implement it as a do-nothing. But the real problem is that delete creates a safety hole. I'd rather keep at least the GC heap as free from corruption as possible.
 Lastly, using multiple heaps like this seems kind of
 inefficient.  There could be tons of free space on the GC heap, and you'd
still be
 allocating on the C heap.
 
 I think it's fine to remove the delete keyword, but at least keep the GC.free
 library function.

IMHO that is too unsafe for any of these arguments to convince me. Andrei
Feb 09 2009
parent reply Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Besides safety concerns, what does forbidding manual deletion enable GC
implementations to do?
Feb 09 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chad J wrote:
 Besides safety concerns, what does forbidding manual deletion enable GC
 implementations to do?

Foregoing delete affords the GC more implementation options. Andrei
Feb 09 2009
next sibling parent reply Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Andrei Alexandrescu wrote:
 Chad J wrote:
 Besides safety concerns, what does forbidding manual deletion enable GC
 implementations to do?

Foregoing delete affords the GC more implementation options. Andrei

Such as? I'm not trying to be antagonistic--manual deletion is a nifty feature to me, so if it gets designed away I'd appreciate knowing what great advantages justified such a sacrifice.
Feb 09 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chad J wrote:
 Andrei Alexandrescu wrote:
 Chad J wrote:
 Besides safety concerns, what does forbidding manual deletion enable GC
 implementations to do?

Andrei

Such as? I'm not trying to be antagonistic--manual deletion is a nifty feature to me, so if it gets designed away I'd appreciate knowing what great advantages justified such a sacrifice.

You need to simply go through a good tutorial on GC implementations, and consider the added costs of offering a manual delete primitive. Andrei
Feb 09 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el  9 de febrero a las 22:20 me escribiste:
 Chad J wrote:
Andrei Alexandrescu wrote:
Chad J wrote:
Besides safety concerns, what does forbidding manual deletion enable GC
implementations to do?

Andrei

I'm not trying to be antagonistic--manual deletion is a nifty feature to me, so if it gets designed away I'd appreciate knowing what great advantages justified such a sacrifice.

You need to simply go through a good tutorial on GC implementations, and consider the added costs of offering a manual delete primitive.

I did read "Garbage Collection: Algorithms for Automatic Dynamic Memory Management"[1] (several times =P) and some papers on the subject and I honestly don't recall any big issues about it. The only case I can think of if copy/compacting collectors that use the heap as a stack when allocating, where freeing a cell in the middle clearly breaks the stack allocation. But in such cases I think delete could be a NOP, just like for now genCollect() really do a fullCollect() because no generational collection is present at the moment, the interface is there. [1] http://www.cs.kent.ac.uk/people/staff/rej/gcbook/gcbook.html -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- More people die from a champagne-cork popping, than from poison spiders
Feb 11 2009
parent reply grauzone <none example.net> writes:
Leandro Lucarella wrote:
 Andrei Alexandrescu, el  9 de febrero a las 22:20 me escribiste:
 Chad J wrote:
 Andrei Alexandrescu wrote:
 Chad J wrote:
 Besides safety concerns, what does forbidding manual deletion enable GC
 implementations to do?

Andrei

I'm not trying to be antagonistic--manual deletion is a nifty feature to me, so if it gets designed away I'd appreciate knowing what great advantages justified such a sacrifice.

the added costs of offering a manual delete primitive.

I did read "Garbage Collection: Algorithms for Automatic Dynamic Memory Management"[1] (several times =P) and some papers on the subject and I honestly don't recall any big issues about it. The only case I can think of if copy/compacting collectors that use the heap as a stack when allocating, where freeing a cell in the middle clearly breaks the stack allocation.

The only issue I see is with copying garbage collectors. But even then, it would be possible to introduce a "force garbage" flag, which causes the collector to ignore a mark bit. Also, D will never ever get a copying garbage collector (except if it's ported to .net, which would break everything else too), so why care about it?
 But in such cases I think delete could be a NOP, just like for now
 genCollect() really do a fullCollect() because no generational collection
 is present at the moment, the interface is there.
 
 [1] http://www.cs.kent.ac.uk/people/staff/rej/gcbook/gcbook.html
 

Feb 11 2009
parent Chad J <gamerchad __spam.is.bad__gmail.com> writes:
grauzone wrote:
 
 Also, D will never ever get a copying garbage collector (except if it's
 ported to .net, which would break everything else too), so why care
 about it?
 

Never is a strong word! Though even if D did get a copying collector it would be come kind of hybrid that also has a conservative collector for backup. Of course we'll probably be on D 4.0 (or later) by the time that happens. Whatever.
Feb 11 2009
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Chad J wrote:
 Besides safety concerns, what does forbidding manual deletion enable GC
 implementations to do?

Andrei

Let's assume this is true and that these options are things that are useful to a language like D. Worst case scenario, a GC implementation could just ignore calls to GC.free(). GC.free() could just be implementation defined as either frees memory or does nothing. As far as safety, D is a systems programming language. If you really want to manually delete a piece of GC-allocated memory, you should be able to. It's good for a systems language to make it harder to screw up _by accident_ (I'm all for getting rid of the delete keyword to make deleting GC-allocated memory less obvious), but if you insist on doing something, the language should assume you have a good reason. Deleting GC allocated memory is an advanced technique that you do at your own risk, just like using C's malloc/free, using pointers, turning off bounds checking, casting, using inline assembly, not initializing variables at declaration, and all the other dangerous but sometimes useful stuff that "safe" languages won't let you do. Disabling this wouldn't absolutely prevent corruption of the GC heap since D still has pointers, which in principle could be made to point anywhere, and since one could still do something stupid like store the only pointer to an object in a region not scanned by the GC via casting or something. The bottom line is that I fail to see how deleting GC-allocated memory is any different than other dangerous but useful things that can be done in D, and unless we want to make D a completely safe language at the expense of the flexibility that its unsafeness offers, I don't understand why you're so opposed to it.
Feb 09 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
dsimcha wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Chad J wrote:
 Besides safety concerns, what does forbidding manual deletion enable GC
 implementations to do?

Andrei

Let's assume this is true and that these options are things that are useful to a language like D. Worst case scenario, a GC implementation could just ignore calls to GC.free(). GC.free() could just be implementation defined as either frees memory or does nothing.

Sure, but making GC.free() offer no guarantee makes it rather useless. It's actually worse than useless because you see a call to GC and you don't know whether or not that could mess up your heap, and you also don't know whether or not that can get you any memory.
 As far as safety, D is a systems programming language.  If you really want to
 manually delete a piece of GC-allocated memory, you should be able to.  It's
good
 for a systems language to make it harder to screw up _by accident_ (I'm all for
 getting rid of the delete keyword to make deleting GC-allocated memory less
 obvious), but if you insist on doing something, the language should assume you
 have a good reason.  Deleting GC allocated memory is an advanced technique that
 you do at your own risk, just like using C's malloc/free, using pointers,
turning
 off bounds checking, casting, using inline assembly, not initializing
variables at
 declaration, and all the other dangerous but sometimes useful stuff that "safe"
 languages won't let you do.  Disabling this wouldn't absolutely prevent
corruption
 of the GC heap since D still has pointers, which in principle could be made to
 point anywhere, and since one could still do something stupid like store the
only
 pointer to an object in a region not scanned by the GC via casting or
something.
 The bottom line is that I fail to see how deleting GC-allocated memory is any
 different than other dangerous but useful things that can be done in D, and
unless
 we want to make D a completely safe language at the expense of the flexibility
 that its unsafeness offers, I don't understand why you're so opposed to it.

Because you have malloc. If you didn't, I'd be all with you. Just use malloc and leave the GC heap alone. It's the perfect setup. Andrei
Feb 09 2009
prev sibling parent grauzone <none example.net> writes:
Andrei Alexandrescu wrote:
 Daniel Keep wrote:
 Denis Koroskin wrote:
 Andrei Alexandrescu Wrote:

 Denis Koroskin wrote:
 On Mon, 09 Feb 2009 13:48:39 +0300, Alex Burton <alexibu mac.com> 
 wrote:

 I think it makes no sense to have nullable pointers in a high 
 level language like D.

 In D :

 X x = new X;
 This is a bit redundant, if we take away the ability to write X x; 
 to mean X x = 0; then we can have X x; mean X x = new X;
 If the class has a ctor then we can write X x(32); instead of X x 
 = new X(32);
 Only when the types of the pointer and class are different do we 
 need to write X x = new Y;
 We can do this syntactically in D because classes cannot be 
 instantiated on the stack (unless scope is used, which I have 
 found a bit pointless, as members are not scope so no 
 deterministic dtor)

 This makes the code much less verbose and allows code to change 
 from X being a struct to X being a class without having to go 
 around and change all the X x; to X = new X;

 As I said in the nullable types thread:
 Passing 0 or 0x012345A or anything else that is not a pointer to 
 an instance of X to a variable declared as X x is the same as 
 mixing in a bicycle when a recipe asks for a cup of olive oil.

 There are much better, and less error prone ways to write code in 
 a high level language than allowing null pointers.

 Alex

value and reference types are instantiated: Foo foo(arg1, arg2); // valid instance, be it reference of value type Bar bar; // same here (default ctor is called) and ditch 'new' keyword altogether.

going under the covers.

determine whether a closure allocates that to determine if Foo foo; allocates But it reduces syntax complexity (by removing one syntax construct) and make structs and classes a little bit more intechangeble, which is a plus, I think.
 Note that you can't delete non-nullable reference so 'delete' 
 keyword is not needed, too (use scope instead). Nullable types, 
 however, may be recycled with e.g. GC.delete(foo);

dangerous. IMHO the delete facility of the GC should be eliminated. (Long story.)

 Andrei


I've used it for managing very large chunks of memory that I don't want hanging around. Access to this memory is generally mediated by small proxy object using reference counting so I know when it's OK to nuke that big chunk. GC is wonderful, but there are times where you just can't trust it. -- Daniel

Sure. My suggested framework is one in which you'd use malloc for those allocations. Then you can free. But plopping delete in the midst of a GC system... that's just uncalled for. Andrei

Using malloc would probably force us to overwrite a class' new operator. Then you no longer had the choice between automatic and manual freeing, because the new operator implementation is fixed. Basically, using malloc would add a load of crap to the program. Having delete (or a function like GC.delete()) is a so much simpler and nicer solution. Why would you remove that?
Feb 10 2009
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Alex Burton wrote:
 I think it makes no sense to have nullable pointers in a high level language
like D.
 
 In D :
 
 X x = new X;
 This is a bit redundant, if we take away the ability to write X x; to mean X x
= 0; then we can have X x; mean X x = new X;
 If the class has a ctor then we can write X x(32); instead of X x = new X(32);
 Only when the types of the pointer and class are different do we need to write
X x = new Y;
 We can do this syntactically in D because classes cannot be instantiated on
the stack (unless scope is used, which I have found a bit pointless, as members
are not scope so no deterministic dtor)
 
 This makes the code much less verbose and allows code to change from X being a
struct to X being a class without having to go around and change all the X x;
to X = new X;
 
 As I said in the nullable types thread:
 Passing 0 or 0x012345A or anything else that is not a pointer to an instance
of X to a variable declared as X x is the same as mixing in a bicycle when a
recipe asks for a cup of olive oil.
 
 There are much better, and less error prone ways to write code in a high level
language than allowing null pointers.
 
 Alex

How would you do this? X x; if(someCondition) { x = new SomeX(); } else { x = new SomeOtherX(); }
Feb 09 2009
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-02-09 06:41:59 -0500, Ary Borenszweig <ary esperanto.org.ar> said:

 How would you do this?
 
 X x;
 
 if(someCondition) {
    x = new SomeX();
 } else {
    x =  new SomeOtherX();
 }

Well, the declaration could be transformed to this: X x = new X; But since x is not used before being reassigned (for all code paths), the compiler could just leave it uninitialized until you do the assignement yourself. But then perhaps the "new X" should not be elided unless the constructor and and destructor are pure. Another question is what happens when X is an abstract class. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 09 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Michel Fortin wrote:
 On 2009-02-09 06:41:59 -0500, Ary Borenszweig <ary esperanto.org.ar> said:
 
 How would you do this?

 X x;

 if(someCondition) {
    x = new SomeX();
 } else {
    x =  new SomeOtherX();
 }

Well, the declaration could be transformed to this: X x = new X; But since x is not used before being reassigned (for all code paths), the compiler could just leave it uninitialized until you do the assignement yourself. But then perhaps the "new X" should not be elided unless the constructor and and destructor are pure.

I don't trust that the compiler would do that.
 Another question is what happens when X is an abstract class.

Or when X has no default constructor. Or when X's default constructor allocates non-memory resources. Or when X's default constructor depends on global variables that those conditionals set and segfaults or throws when those globals are not in a consistent state. Or when X is a really huge class or does a lot of computation in its constructor and allocating it takes an unreasonable amount of time. Any case in which the default constructor has side effects or preconditions is a problem.
Feb 09 2009
parent reply Denis Koroskin <2korden gmail.com> writes:
Christopher Wright Wrote:

 Michel Fortin wrote:
 On 2009-02-09 06:41:59 -0500, Ary Borenszweig <ary esperanto.org.ar> said:
 
 How would you do this?

 X x;

 if(someCondition) {
    x = new SomeX();
 } else {
    x =  new SomeOtherX();
 }

Well, the declaration could be transformed to this: X x = new X; But since x is not used before being reassigned (for all code paths), the compiler could just leave it uninitialized until you do the assignement yourself. But then perhaps the "new X" should not be elided unless the constructor and and destructor are pure.

I don't trust that the compiler would do that.
 Another question is what happens when X is an abstract class.

Or when X has no default constructor. Or when X's default constructor allocates non-memory resources. Or when X's default constructor depends on global variables that those conditionals set and segfaults or throws when those globals are not in a consistent state. Or when X is a really huge class or does a lot of computation in its constructor and allocating it takes an unreasonable amount of time. Any case in which the default constructor has side effects or preconditions is a problem.

1) It is a valid C++ construct, and I don't remember having any problem with it. 2) It's just a shortcut for Foo foo = new Foo(). If you don't plan to instanciate the instance immediately, i.e. you want to leave it as null, you should mark it as nullable: Foo? foo; // no ctor call made
Feb 09 2009
parent Christopher Wright <dhasenan gmail.com> writes:
Denis Koroskin wrote:
 Christopher Wright Wrote:
 Any case in which the default constructor has side effects or 
 preconditions is a problem.

1) It is a valid C++ construct, and I don't remember having any problem with it. 2) It's just a shortcut for Foo foo = new Foo(). If you don't plan to instanciate the instance immediately, i.e. you want to leave it as null, you should mark it as nullable: Foo? foo; // no ctor call made

Okay, so your proposal relies on the nullable types proposal, which I dislike; and given the nullable types proposal, this is reasonable.
Feb 11 2009
prev sibling next sibling parent Don <nospam nospam.com> writes:
Ary Borenszweig wrote:
 Alex Burton wrote:
 I think it makes no sense to have nullable pointers in a high level 
 language like D.

 In D :

 X x = new X;
 This is a bit redundant, if we take away the ability to write X x; to 
 mean X x = 0; then we can have X x; mean X x = new X;
 If the class has a ctor then we can write X x(32); instead of X x = 
 new X(32);
 Only when the types of the pointer and class are different do we need 
 to write X x = new Y;
 We can do this syntactically in D because classes cannot be 
 instantiated on the stack (unless scope is used, which I have found a 
 bit pointless, as members are not scope so no deterministic dtor)

 This makes the code much less verbose and allows code to change from X 
 being a struct to X being a class without having to go around and 
 change all the X x; to X = new X;

 As I said in the nullable types thread:
 Passing 0 or 0x012345A or anything else that is not a pointer to an 
 instance of X to a variable declared as X x is the same as mixing in a 
 bicycle when a recipe asks for a cup of olive oil.

 There are much better, and less error prone ways to write code in a 
 high level language than allowing null pointers.

 Alex

How would you do this? X x; if(someCondition) { x = new SomeX(); } else { x = new SomeOtherX(); }

That's interesting, because even there, you don't want X to be a nullable type. You don't want x to be readable AT ALL until one of the constructor calls has happened. In fact, there's already a syntax for this. The solution is: X x = void; if(someCondition) { x = new SomeX(); } else { x = new SomeOtherX(); }
Feb 09 2009
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Ary Borenszweig wrote:
 How would you do this?
 
 X x;
 
 if(someCondition) {
   x = new SomeX();
 } else {
   x =  new SomeOtherX();
 }

One option is the "turn everything into an expression" route. This is what Nemerle (think a functional superset of C#) did, and it's just BEAUTIFULLY expressive.
 X x = if( someCondition ) new SomeX(); else new SomeOtherX();

Failing that, there's always this (note: didn't do a syntax check on this :P):
 X x = ({if(someCondition)
     return new SomeX();
     else return new SomeOtherX();})();

Or something to that effect. -- Daniel
Feb 09 2009
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Daniel Keep wrote:
 One option is the "turn everything into an expression" route.  This is
 what Nemerle (think a functional superset of C#) did, and it's just
 BEAUTIFULLY expressive.
 
 X x = if( someCondition ) new SomeX(); else new SomeOtherX();

Failing that, there's always this (note: didn't do a syntax check on this :P):
 X x = ({if(someCondition)
     return new SomeX();
     else return new SomeOtherX();})();

Or something to that effect.

Like this? X x = (someCondition) ? new SomeX() : new SomeOtherX(); *Much* preferred to delegate trickery, I'd think...
Feb 09 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Frits van Bommel wrote:
 Daniel Keep wrote:
 One option is the "turn everything into an expression" route.  This is
 what Nemerle (think a functional superset of C#) did, and it's just
 BEAUTIFULLY expressive.

 X x = if( someCondition ) new SomeX(); else new SomeOtherX();

Failing that, there's always this (note: didn't do a syntax check on this :P):
 X x = ({if(someCondition)
     return new SomeX();
     else return new SomeOtherX();})();

Or something to that effect.

Like this? X x = (someCondition) ? new SomeX() : new SomeOtherX(); *Much* preferred to delegate trickery, I'd think...

Replace "new SomeX();" with two statements. -- Daniel
Feb 09 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 09 Feb 2009 14:41:59 +0300, Ary Borenszweig <ary esperanto.org.ar>
wrote:

[skip]
 How would you do this?

 X x;

 if(someCondition) {
    x = new SomeX();
 } else {
    x =  new SomeOtherX();
 }

Note: I am not talking about an "X x(42);" shortcut now, see the subject. This is a good question, I think. One way to do it is as follows: [code] T enforce(T? t); X? tmp; // null if (someCondition) { tmp = new SomeX(); } else { tmp = new SomeOtherX(); } X x = enforce(tmp); [/code] But it is too verbose and has one (potentially unsafe) operation (enforce). A check is moved from compile-time to run-time, which is what we wanted to avoid when introduced non-nullable references. Here is my alternative - just like that, there is no need for extra syntax. X x; if(someCondition) { x = new SomeX(); } else { x = new SomeOtherX(); } For example, the following code is *invalid* C#: [code] X x; if (someCondition) { X = new SomeX(); } foo(x); // error: Use of unassigned local variable 'x' [/code] However, if you initialize the variable at all code-paths, then it is ok: [code] X x; if (someCondition) { x = new SomeX(); } else { x = new SomeOtherX(); } foo(x); [/code] The only difference is that 'x' is allowed to be null-initialized in C#: X x = null; foo(x); // ok, x is /initialized/ (to null) Making it a compile-time error (x is non-nullable) in D will solve the issue. Other issue is non-nullable objects as members - how would you make sure that they are properly initialized prior to first access to them? class Foo {} class Bar { private Foo x; private Foo y; this() { // how would you initialize x and y? } } A C++ solution would be to initialize them in the initialization list: Bar::Bar() : x(new Foo()), y(new Foo()) { } but it is not flexible enough and we don't have it in D anyway. As a solution, local variable initialization rules could be extended to member variables - you should have all non-nullable members initialized before you successfully leave the ctor scope and before you pass this to some function or store it in global variable to ensure that 'this' is not visible outside of the ctor scope until all members initialized: class Bar : Exception { private Foo x; private Foo y; this() { //super(""); error, base class ctor may call virtual method (e.g., toString) that potentially may access x or y. // gFoo = this; // error: x and y are not initalized, possible use of uninitialized variables detected x = new Foo(); if (someCondition) { throw new Exception("Just an example"); // okay, object is not constructed } // throw this; // error: y is not initialized // y = new Foo(this); // error: y is not initialized yet y = new Foo(x); // okay, x is fine super(""); someFunc(this); // okay, all members are initialized by now } } Do you have any other ideas to solve the issue above?
Feb 09 2009
prev sibling next sibling parent Alex Burton <alexibu mac.com> writes:
Ary Borenszweig Wrote:

 Alex Burton wrote:
 I think it makes no sense to have nullable pointers in a high level language
like D.
 
 In D :
 
 X x = new X;
 This is a bit redundant, if we take away the ability to write X x; to mean X x
= 0; then we can have X x; mean X x = new X;
 If the class has a ctor then we can write X x(32); instead of X x = new X(32);
 Only when the types of the pointer and class are different do we need to write
X x = new Y;
 We can do this syntactically in D because classes cannot be instantiated on
the stack (unless scope is used, which I have found a bit pointless, as members
are not scope so no deterministic dtor)
 
 This makes the code much less verbose and allows code to change from X being a
struct to X being a class without having to go around and change all the X x;
to X = new X;
 
 As I said in the nullable types thread:
 Passing 0 or 0x012345A or anything else that is not a pointer to an instance
of X to a variable declared as X x is the same as mixing in a bicycle when a
recipe asks for a cup of olive oil.
 
 There are much better, and less error prone ways to write code in a high level
language than allowing null pointers.
 
 Alex

How would you do this? X x; if(someCondition) { x = new SomeX(); } else { x = new SomeOtherX(); }

I would try to never write code like that. The reason being if the if statement becomes a bit more complicated you risk leaving x = 0; Better to write a small function: X getX(bool someCondition) { if(someCondition) { return new SomeX(); } else { return new SomeOtherX(); } } That way the compiler will have to tell you if X can be possibly returned null. Alex
Feb 09 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
Note there exists an *very* similar issue - invariant/immutable variables
initialization:

class Bar : Base
{
    invariant this()
    {
        // how would you initialize _x and _y?
        // they should be initialized before 'this' laves the scope
        // and before super() ("Foo x()" might be called by base class)
    }

    invariant Foo x()
    {
        return _x;
    }  

    private invariant Foo _x, _y;
}

My proposed rules apply to this situation quite the same.
Feb 09 2009
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Alex Burton wrote:
 I think it makes no sense to have nullable pointers in a high level language
like D.

Oh, and how do you intend to make linked lists? Or trees? Or any non-trivial data structure? Saying they have no place in a language is just silly; the question should be whether they should be the default or not (I would contend that they shouldn't be.)
 In D :
 
 X x = new X;
 This is a bit redundant, if we take away the ability to write X x; to mean X x
= 0; then we can have X x; mean X x = new X;
 If the class has a ctor then we can write X x(32); instead of X x = new X(32);

Can I just say that I *LOATHE* this syntax? It's one thing I always despised about C++; it simply makes NO sense whatsoever. It looks like the bastard offspring of a function declaration and a function call. The first *is* redundant, but then I wouldn't state X twice, I'd use "auto" (because types are almost never a single letter anyway.) Add to that that the existing syntax is much more intuitive; it even reads like a sentence.
 Only when the types of the pointer and class are different do we need to write
X x = new Y;
 We can do this syntactically in D because classes cannot be instantiated on
the stack (unless scope is used, which I have found a bit pointless, as members
are not scope so no deterministic dtor)

I made a proposal quite some time ago detailing how we could have not only scope members of classes, but even scope RETURN values, but I think it got maybe one reply... :P Given that one of D's tenets is to make it simpler to write deterministic, bullet-proof code, the complete lack of deterministic destruction of classes has always felt like a huge hole in the language.
 This makes the code much less verbose and allows code to change from X being a
struct to X being a class without having to go around and change all the X x;
to X = new X;

Something interesting about C# that I'd forgotten until recently...
 Vector2 v = new Vector2();

What is Vector2? ... It's a struct. In C#, there's no syntactic difference between instantiating a class and initialising a struct. Most C# code doesn't have pointers, so this isn't an issue. (Note that I don't have any idea how you would heap-allocate a value type in C#; I'm not even sure if it's possible...)
 As I said in the nullable types thread:
 Passing 0 or 0x012345A or anything else that is not a pointer to an instance
of X to a variable declared as X x is the same as mixing in a bicycle when a
recipe asks for a cup of olive oil.

Passing garbage to a function doesn't have any bearing on the non-nullable discussion. If you're casting random integers to pointers and passing them to functions, you reap what you sow. :) That said, passing null is more like omitting an ingredient. Which is unfortunate if you're making soup and the ingredient is "water."
 There are much better, and less error prone ways to write code in a high level
language than allowing null pointers.
 
 Alex

While I'm a strong believer in non-nullable types, I don't think null pointers are evil. They're a tool like anything else; problems only arise when you misue them. I believe they're the wrong default choice, because they don't come up in normal code, but you've got to fall over yourself to make sure they don't become an issue. Let me chip in a practical example that happened just yesterday. I'm throwing together a game prototype. Since this is C#, I don't have contracts, so I'm making judicious use of Debug.Assert calls to ensure that object references are non-null. And surprise, surprise, my program crashes with null dereference errors. I walk the stack trace back, only to discover that the null got stored at some point. So the program doesn't even crash when the problem occurs (storing a null reference in a field that shouldn't have one) it occurs later in the execution when I'm no longer able to easily determine what went wrong. Eventually, I tracked it down to one of the few places in the code that I forgot to assert the reference was non-null. It was null because Microsoft didn't bother to document that a particular "magic object" doesn't exist until a certain point. -- Daniel
Feb 09 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:gmpd71$8uj$1 digitalmars.com...
 Alex Burton wrote:
 I think it makes no sense to have nullable pointers in a high level 
 language like D.

Oh, and how do you intend to make linked lists? Or trees? Or any non-trivial data structure?

Null Object Pattern: -------------- class LinkedListNode(T) { LinkedListNode!(T) next; private static LinkedListNode!(T) _end; static LinkedListNode!(T) end() { return _end; } static this() { _end = new LinkedListNode!(T); } } -------------- However, I admit this is little more than re-inventing null. But it's at least possible.
 Saying they have no place in a language is just silly; the question
 should be whether they should be the default or not (I would contend
 that they shouldn't be.)

Agreed.
 In D :

 X x = new X;
 This is a bit redundant, if we take away the ability to write X x; to 
 mean X x = 0; then we can have X x; mean X x = new X;
 If the class has a ctor then we can write X x(32); instead of X x = new 
 X(32);

Can I just say that I *LOATHE* this syntax? It's one thing I always despised about C++; it simply makes NO sense whatsoever. It looks like the bastard offspring of a function declaration and a function call. The first *is* redundant, but then I wouldn't state X twice, I'd use "auto" (because types are almost never a single letter anyway.) Add to that that the existing syntax is much more intuitive; it even reads like a sentence.

Just a thought: Would you hate this less: X(32) x;
 Only when the types of the pointer and class are different do we need to 
 write X x = new Y;
 We can do this syntactically in D because classes cannot be instantiated 
 on the stack (unless scope is used, which I have found a bit pointless, 
 as members are not scope so no deterministic dtor)

I made a proposal quite some time ago detailing how we could have not only scope members of classes, but even scope RETURN values, but I think it got maybe one reply... :P Given that one of D's tenets is to make it simpler to write deterministic, bullet-proof code, the complete lack of deterministic destruction of classes has always felt like a huge hole in the language.

I don't suppose you have a link or the subject line of that handy?
 As I said in the nullable types thread:
 Passing 0 or 0x012345A or anything else that is not a pointer to an 
 instance of X to a variable declared as X x is the same as mixing in a 
 bicycle when a recipe asks for a cup of olive oil.

Passing garbage to a function doesn't have any bearing on the non-nullable discussion. If you're casting random integers to pointers and passing them to functions, you reap what you sow. :) That said, passing null is more like omitting an ingredient. Which is unfortunate if you're making soup and the ingredient is "water."

I have to say, I'm loving these analogies :-)
 While I'm a strong believer in non-nullable types, I don't think null
 pointers are evil.  They're a tool like anything else; problems only
 arise when you misue them.

 I believe they're the wrong default choice, because they don't come up
 in normal code, but you've got to fall over yourself to make sure they
 don't become an issue.

That's pretty much my opinion on the matter as well. Null Object Pattern is a usable alternative to nullables, and even more powerful (the "null" is capable of functions, data and polymorphism), but in the cases when you don't need that extra power, a non-default nullable is just less work and isn't really any less safe.
 Eventually, I tracked it down to one of the few places in the code that
 I forgot to assert the reference was non-null.  It was null because
 Microsoft didn't bother to document that a particular "magic object"
 doesn't exist until a certain point.

C#/.NET does seem to have some odd quirks like that. A few weeks ago, I was pulling my hair out figuring out a particular bug, and stepping through in the debugger only perplexed me more. Turned out there was an object with a property I was setting, but the new value was somehow "queued" and didn't actually take until later on. The docs hadn't mentioned that particular behavior.
Feb 09 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Nick Sabalausky wrote:
 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
 news:gmpd71$8uj$1 digitalmars.com...
 Alex Burton wrote:
 I think it makes no sense to have nullable pointers in a high level 
 language like D.

non-trivial data structure?

Null Object Pattern: -------------- class LinkedListNode(T) { LinkedListNode!(T) next; private static LinkedListNode!(T) _end; static LinkedListNode!(T) end() { return _end; } static this() { _end = new LinkedListNode!(T); } } -------------- However, I admit this is little more than re-inventing null. But it's at least possible.

And don't forget that in doing this, you've lost the benefit of dereferencing a null crashing the program: if you accidentally access the _end member, you won't notice unless you explicitly check for it.
 [snip]
 In D :

 ... we can write X x(32); instead of X x = new
 X(32);

despised about C++; it simply makes NO sense whatsoever. It looks like the bastard offspring of a function declaration and a function call. ...

Just a thought: Would you hate this less: X(32) x;

That's just as bad; it looks like a parameterised type where you forgot the '!'.
 I made a proposal quite some time ago detailing how we could have not
 only scope members of classes, but even scope RETURN values, but I think
 it got maybe one reply... :P

 Given that one of D's tenets is to make it simpler to write
 deterministic, bullet-proof code, the complete lack of deterministic
 destruction of classes has always felt like a huge hole in the language.

I don't suppose you have a link or the subject line of that handy?

Took me a while to find it, even knowing what it was about. Ended up having to manually go through the digitalmars.com archives. :P http://www.digitalmars.com/d/archives/digitalmars/D/38329.html It's probably somewhat anachronistic now. For anyone who isn't aware, back in the old days, 'scope' was 'auto' whilst 'auto' was 'auto.' It sort of did two things and was a bit confusing. Just replace 'auto' with 'scope' and you should be fine. :P Also, back then auto didn't stack-allocate. If I may digress to the land of make-believe for a moment: if this proposal was implemented, you could get around the whole "stack allocation" thing like this: { scope X foo() { return new X; } scope X x = foo(); } Which could become this: { void foo(ubyte[] storage, inout X ptr) { static if( X.sizeofinstance > storage.length ) { ptr = new X; } else { storage[0..X.sizeofinstance] = cast(ubyte[])(new X); } } ubyte[X.sizeofinstance] x_storage; scope X x = x_storage.ptr; foo(x_storage, x); } The caller allocates enough space for an instance of X and passes both the storage and the actual reference variable. The caller can then either store the instance in that array, or make the reference point to somewhere else. Just a thought. :P </digression>
 [snip]
 While I'm a strong believer in non-nullable types, I don't think null
 pointers are evil.  They're a tool like anything else; problems only
 arise when you misue them.

 I believe they're the wrong default choice, because they don't come up
 in normal code, but you've got to fall over yourself to make sure they
 don't become an issue.

That's pretty much my opinion on the matter as well. Null Object Pattern is a usable alternative to nullables, and even more powerful (the "null" is capable of functions, data and polymorphism), but in the cases when you don't need that extra power, a non-default nullable is just less work and isn't really any less safe.

I'd argue it's more safe because it'll crash your program faster. :D
 Eventually, I tracked it down to one of the few places in the code that
 I forgot to assert the reference was non-null.  It was null because
 Microsoft didn't bother to document that a particular "magic object"
 doesn't exist until a certain point.

C#/.NET does seem to have some odd quirks like that. A few weeks ago, I was pulling my hair out figuring out a particular bug, and stepping through in the debugger only perplexed me more. Turned out there was an object with a property I was setting, but the new value was somehow "queued" and didn't actually take until later on. The docs hadn't mentioned that particular behavior.

Microsoft just seems to be really bad at documentation. They go to all that effort of creating a tremendous amount of documentation, but don't succeed in actually saying anything. My favourites are the innumerable classes in .NET or XNA that document every single member function and property... but fail to state what any of them ACTUALLY DO. Or what the arguments are for. Or what the valid values are. Or under what circumstances it's usable. Or how to even create the bloody things. -- Daniel
Feb 10 2009
parent "Nick Sabalausky" <a a.a> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:gmrfe8$10l4$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message
 news:gmpd71$8uj$1 digitalmars.com...

Took me a while to find it, even knowing what it was about. Ended up having to manually go through the digitalmars.com archives. :P http://www.digitalmars.com/d/archives/digitalmars/D/38329.html It's probably somewhat anachronistic now. For anyone who isn't aware, back in the old days, 'scope' was 'auto' whilst 'auto' was 'auto.' It sort of did two things and was a bit confusing. Just replace 'auto' with 'scope' and you should be fine. :P

Interesting. I'd love to see this get some more attention and discussion simply because what you had said earlier is also one of my own pet peeves about D, and I couldn't have descrbed it any better than you did:
 Given that one of D's tenets is to make it simpler to write
 deterministic, bullet-proof code, the complete lack of deterministic
 destruction of classes has always felt like a huge hole in the language.



Feb 10 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
 news:gmpd71$8uj$1 digitalmars.com...
 Alex Burton wrote:
 I think it makes no sense to have nullable pointers in a high level 
 language like D.

non-trivial data structure?

Null Object Pattern: -------------- class LinkedListNode(T) { LinkedListNode!(T) next; private static LinkedListNode!(T) _end; static LinkedListNode!(T) end() { return _end; } static this() { _end = new LinkedListNode!(T); } } --------------

What is "next" for the _end node? Andrei
Feb 10 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Tue, 10 Feb 2009 17:11:06 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Nick Sabalausky wrote:
 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
 news:gmpd71$8uj$1 digitalmars.com...
 Alex Burton wrote:
 I think it makes no sense to have nullable pointers in a high level 
 language like D.

non-trivial data structure?

-------------- class LinkedListNode(T) { LinkedListNode!(T) next; private static LinkedListNode!(T) _end; static LinkedListNode!(T) end() { return _end; } static this() { _end = new LinkedListNode!(T); } } --------------

What is "next" for the _end node? Andrei

Perhaps, 'this' (i.e. itself).

Then there's going to be quite a few infinite loops out there... Andrei
Feb 10 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Tue, 10 Feb 2009 17:40:36 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Denis Koroskin wrote:
 On Tue, 10 Feb 2009 17:11:06 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Nick Sabalausky wrote:
 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
 news:gmpd71$8uj$1 digitalmars.com...
 Alex Burton wrote:
 I think it makes no sense to have nullable pointers in a high 
 level language like D.

non-trivial data structure?

-------------- class LinkedListNode(T) { LinkedListNode!(T) next; private static LinkedListNode!(T) _end; static LinkedListNode!(T) end() { return _end; } static this() { _end = new LinkedListNode!(T); } } --------------

What is "next" for the _end node? Andrei


Then there's going to be quite a few infinite loops out there... Andrei

No, you just need to have a private ctor:

I meant that code that fails to check for _end when iterating through a list will never stop. Andrei
Feb 10 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Tue, 10 Feb 2009 19:41:25 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Denis Koroskin wrote:
 On Tue, 10 Feb 2009 17:40:36 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:
 On Tue, 10 Feb 2009 17:11:06 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Nick Sabalausky wrote:
 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
 news:gmpd71$8uj$1 digitalmars.com...
 Alex Burton wrote:
 I think it makes no sense to have nullable pointers in a high 
 level language like D.

non-trivial data structure?

-------------- class LinkedListNode(T) { LinkedListNode!(T) next; private static LinkedListNode!(T) _end; static LinkedListNode!(T) end() { return _end; } static this() { _end = new LinkedListNode!(T); } } --------------

What is "next" for the _end node? Andrei


Then there's going to be quite a few infinite loops out there... Andrei


I meant that code that fails to check for _end when iterating through a list will never stop. Andrei

No, error like that will be detected at compile time (comparison against null is disallowed for non-nullable reference).

I must be misunderstanding something. At the highest level, the example given replaced the terminating node of a list (which traditionally is null) with a node that had itself as the next node. This means that if you iterate such a list without testing for node == _end, you will have an infinite loop. This has nothing to do with types. Andrei
Feb 10 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gmsd6o$2h77$1 digitalmars.com...
 I must be misunderstanding something. At the highest level, the example 
 given replaced the terminating node of a list (which traditionally is 
 null) with a node that had itself as the next node.

 This means that if you iterate such a list without testing for node == 
 _end, you will have an infinite loop. This has nothing to do with types.

------------------ class LinkedListNode(T) { static this() { _end = new LinkedListNode!(T)(55555); } this() { // Prevent _next from being auto-inited to // a new LinkedListNode, which in turn // would have a _next auto-inited to a // new LinkedListNode, etc. _next = _end; } // Prevent _end._next from being auto-inited to // a new LinkedListNode, which in turn // would have a _next auto-inited to a // new LinkedListNode, etc. private this(int dummy) { _next = this; } private static LinkedListNode!(T) _end; static LinkedListNode!(T) end() { return _end; } private LinkedListNode!(T) _next; void next(LinkedListNode!(T) newNext) { _next = newNext; } LinkedListNode!(T) next() { // Prevent infinite iteration if(this is _end) throw new Exception("Iterated past the end!"); else return _next; } } ------------------ Note, however, that I'm not advocating this approach to linked lists or other advanced structures (since it's so much uglier than just using a nullable reference). I'm just pointing out that it's at least *possible* without using nullable references.
Feb 10 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gmsd6o$2h77$1 digitalmars.com...
 I must be misunderstanding something. At the highest level, the example 
 given replaced the terminating node of a list (which traditionally is 
 null) with a node that had itself as the next node.

 This means that if you iterate such a list without testing for node == 
 _end, you will have an infinite loop. This has nothing to do with types.

------------------ class LinkedListNode(T)

Oh ok, now I understand. Thanks. Andrei
Feb 10 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 10 Feb 2009 17:11:06 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Nick Sabalausky wrote:
 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message  
 news:gmpd71$8uj$1 digitalmars.com...
 Alex Burton wrote:
 I think it makes no sense to have nullable pointers in a high level  
 language like D.

non-trivial data structure?

-------------- class LinkedListNode(T) { LinkedListNode!(T) next; private static LinkedListNode!(T) _end; static LinkedListNode!(T) end() { return _end; } static this() { _end = new LinkedListNode!(T); } } --------------

What is "next" for the _end node? Andrei

Perhaps, 'this' (i.e. itself).
Feb 10 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 10 Feb 2009 17:40:36 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:
 On Tue, 10 Feb 2009 17:11:06 +0300, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 Nick Sabalausky wrote:
 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message  
 news:gmpd71$8uj$1 digitalmars.com...
 Alex Burton wrote:
 I think it makes no sense to have nullable pointers in a high level  
 language like D.

non-trivial data structure?

-------------- class LinkedListNode(T) { LinkedListNode!(T) next; private static LinkedListNode!(T) _end; static LinkedListNode!(T) end() { return _end; } static this() { _end = new LinkedListNode!(T); } } --------------

What is "next" for the _end node? Andrei


Then there's going to be quite a few infinite loops out there... Andrei

No, you just need to have a private ctor: class LinkedListNode(T) { private enum Foo { Bar, } private this(Foo foo) // not accessible outside of the module { _next = this; } static this() { _end = new LinkedListNode!(T)(Foo.Bar); } private LinkedListNode _next; }
Feb 10 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 10 Feb 2009 19:41:25 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:
 On Tue, 10 Feb 2009 17:40:36 +0300, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:
 On Tue, 10 Feb 2009 17:11:06 +0300, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 Nick Sabalausky wrote:
 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message  
 news:gmpd71$8uj$1 digitalmars.com...
 Alex Burton wrote:
 I think it makes no sense to have nullable pointers in a high  
 level language like D.

non-trivial data structure?

-------------- class LinkedListNode(T) { LinkedListNode!(T) next; private static LinkedListNode!(T) _end; static LinkedListNode!(T) end() { return _end; } static this() { _end = new LinkedListNode!(T); } } --------------

What is "next" for the _end node? Andrei


Then there's going to be quite a few infinite loops out there... Andrei


I meant that code that fails to check for _end when iterating through a list will never stop. Andrei

No, error like that will be detected at compile time (comparison against null is disallowed for non-nullable reference).
Feb 10 2009
prev sibling parent reply grauzone <none example.net> writes:
Alex Burton wrote:
 I think it makes no sense to have nullable pointers in a high level language
like D.
 
 In D :
 
 X x = new X;
 This is a bit redundant, if we take away the ability to write X x; to mean X x
= 0; then we can have X x; mean X x = new X;
 If the class has a ctor then we can write X x(32); instead of X x = new X(32);
 Only when the types of the pointer and class are different do we need to write
X x = new Y;

Add this code to your class X: static X opCall(T...)(T x) { return new X(x); } Then you can write:
 auto x = X();

Can it get any less redundant? The opCall is a bit annoying, but needs to be written only once.
 We can do this syntactically in D because classes cannot be instantiated on
the stack (unless scope is used, which I have found a bit pointless, as members
are not scope so no deterministic dtor)
 
 This makes the code much less verbose and allows code to change from X being a
struct to X being a class without having to go around and change all the X x;
to X = new X;

For structs, use opCall() to initialize them. opCall is the best way to initialize a struct, because struct literal are totally utterly useless. If you use opCall to initialize classes as well (see above), then the syntax for initializing structs and classes will be exactly the same.
 As I said in the nullable types thread:
 Passing 0 or 0x012345A or anything else that is not a pointer to an instance
of X to a variable declared as X x is the same as mixing in a bicycle when a
recipe asks for a cup of olive oil.
 
 There are much better, and less error prone ways to write code in a high level
language than allowing null pointers.

Like what?
 Alex

Feb 09 2009
parent "Nick Sabalausky" <a a.a> writes:
"grauzone" <none example.net> wrote in message 
news:gmpe6g$adf$2 digitalmars.com...
 Alex Burton wrote:

 For structs, use opCall() to initialize them. opCall is the best way to 
 initialize a struct, because struct literal are totally utterly useless.

 If you use opCall to initialize classes as well (see above), then the 
 syntax for initializing structs and classes will be exactly the same.

That's good advice for using D today, but it's still subject to human error. Making "X x;" serve as an implicit "X x = new X();" for classes would eliminate that human error.
Feb 09 2009