www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - difference between x = Nullable.init and x.nullify

reply vit <vit vit.vit> writes:
Hello,
What's the difference between x = Nullable!Test.init and 
x.nullify?


class Test{}

void test()pure nothrow{
     Nullable!Test x;

     x = Nullable!Test.init; //OK
     x.nullify;              //Error: function 
'std.typecons.Nullable!(Test).Nullable.nullify!().nullify' is not 
nothrow

}
Jun 02
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Saturday, June 03, 2017 05:52:55 vit via Digitalmars-d-learn wrote:
 Hello,
 What's the difference between x = Nullable!Test.init and
 x.nullify?


 class Test{}

 void test()pure nothrow{
      Nullable!Test x;

      x = Nullable!Test.init; //OK
      x.nullify;              //Error: function
 'std.typecons.Nullable!(Test).Nullable.nullify!().nullify' is not
 nothrow

 }
Assigning Nullable!Test.init is equivalent to setting the internal value to Test.init and setting _isNull to false. nullify doesn't assign Nullable!Test.init to the Nullable!Test, and it doesn't assign Test.init to _value. Rather, it calls destroy on _value and sets _isNull to true. Exactly what destroy does depends on the type. In the case of a class, it calls rt_finalize on it, which basically calls the class' finalizer (if it has one). But rt_finalize is not nothrow, so destroy isn't nothrow, so nullify isn't nothrow. However, looking at what rt_finalize does, I don't see why it couldn't be nothrow. So, unless I'm missing something, it seems like that would be a good enhancement. - Jonathan M Davis
Jun 02
next sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Saturday, 3 June 2017 at 06:19:29 UTC, Jonathan M Davis wrote:

 looking at what rt_finalize does, I don't see why it couldn't 
 be nothrow. So, unless I'm missing something, it seems like 
 that would be a good enhancement.

 - Jonathan M Davis
Presently, rt_finalize cannot be made nothrow, or un-made system, because "reasons": http://forum.dlang.org/thread/aalafajtuhlvfirwfvea forum.dlang.org Fixing that would require significant changes to the runtime, and probably the compiler. I don't think it qualifies as a simple "enhancement" :)
Jun 02
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Saturday, June 03, 2017 06:41:44 Stanislav Blinov via Digitalmars-d-learn 
wrote:
 On Saturday, 3 June 2017 at 06:19:29 UTC, Jonathan M Davis wrote:
 looking at what rt_finalize does, I don't see why it couldn't
 be nothrow. So, unless I'm missing something, it seems like
 that would be a good enhancement.

 - Jonathan M Davis
Presently, rt_finalize cannot be made nothrow, or un-made system, because "reasons": http://forum.dlang.org/thread/aalafajtuhlvfirwfvea forum.dlang.org Fixing that would require significant changes to the runtime, and probably the compiler. I don't think it qualifies as a simple "enhancement" :)
Well, as I said, I could be missing something, but all rt_finalize does is call rt_finalize2, and rt_finalize2 _is_ nothrow (it catches any Exceptions that are thrown by the destructor/finalizer). So, I have no idea why it would be the case that rt_finalize couldn't be nothrow, and I saw nothing in that thread which contradicts that, but I could have read it too quickly. Regardless, it's a perfectly valid enhancement request whether it's easy to implement or not. - Jonathan M Davis
Jun 03
parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Saturday, 3 June 2017 at 08:01:14 UTC, Jonathan M Davis wrote:
 On Saturday, June 03, 2017 06:41:44 Stanislav Blinov via 
 Digitalmars-d-learn wrote:
 On Saturday, 3 June 2017 at 06:19:29 UTC, Jonathan M Davis 
 wrote:
 looking at what rt_finalize does, I don't see why it 
 couldn't be nothrow. So, unless I'm missing something, it 
 seems like that would be a good enhancement.

 - Jonathan M Davis
Presently, rt_finalize cannot be made nothrow, or un-made system, because "reasons": http://forum.dlang.org/thread/aalafajtuhlvfirwfvea forum.dlang.org Fixing that would require significant changes to the runtime, and probably the compiler. I don't think it qualifies as a simple "enhancement" :)
Well, as I said, I could be missing something, but all rt_finalize does is call rt_finalize2, and rt_finalize2 _is_ nothrow (it catches any Exceptions that are thrown by the destructor/finalizer). So, I have no idea why it would be the case that rt_finalize couldn't be nothrow, and I saw nothing in that thread which contradicts that, but I could have read it too quickly. Regardless, it's a perfectly valid enhancement request whether it's easy to implement or not. - Jonathan M Davis
Whoops, my bad, I forgot it indeed swallows exceptions and does the onFinalizeError instead. So... yep, then it seems that rt_finalize probably should be marked nothrow too. Hmm... if throwing in a destructor is considered a runtime error, perhaps another valid enhancement would be to statically disallow throwing Exceptions in destructors, i.e. *require* them be nothrow?..
Jun 03
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Saturday, June 03, 2017 08:17:18 Stanislav Blinov via Digitalmars-d-learn 
wrote:
 On Saturday, 3 June 2017 at 08:01:14 UTC, Jonathan M Davis wrote:
 On Saturday, June 03, 2017 06:41:44 Stanislav Blinov via

 Digitalmars-d-learn wrote:
 On Saturday, 3 June 2017 at 06:19:29 UTC, Jonathan M Davis

 wrote:
 looking at what rt_finalize does, I don't see why it
 couldn't be nothrow. So, unless I'm missing something, it
 seems like that would be a good enhancement.

 - Jonathan M Davis
Presently, rt_finalize cannot be made nothrow, or un-made system, because "reasons": http://forum.dlang.org/thread/aalafajtuhlvfirwfvea forum.dlang.org Fixing that would require significant changes to the runtime, and probably the compiler. I don't think it qualifies as a simple "enhancement" :)
Well, as I said, I could be missing something, but all rt_finalize does is call rt_finalize2, and rt_finalize2 _is_ nothrow (it catches any Exceptions that are thrown by the destructor/finalizer). So, I have no idea why it would be the case that rt_finalize couldn't be nothrow, and I saw nothing in that thread which contradicts that, but I could have read it too quickly. Regardless, it's a perfectly valid enhancement request whether it's easy to implement or not. - Jonathan M Davis
Whoops, my bad, I forgot it indeed swallows exceptions and does the onFinalizeError instead. So... yep, then it seems that rt_finalize probably should be marked nothrow too. Hmm... if throwing in a destructor is considered a runtime error, perhaps another valid enhancement would be to statically disallow throwing Exceptions in destructors, i.e. *require* them be nothrow?..
My initial reaction would be that destructors should always be nothrow, though I vaguely recall there being some reason why it was supposed to be nice that destructors in D could cleanly deal with exceptions. And remember that when we're talking about rt_finalize, we're talking about finalizers, not destructors in general. When a destructor is in a GC heap-allocated object, it's treated as a finalizer and may or may not be run (since the object may or may not be collected), whereas when a destructor is on an object that's on the stack, it's really a destructor. So, while they use the same syntax, and in the case of a struct, the same function could be either a destructor or a finalizer depending on where the struct is declared, they're not quite the same thing. And destroy muddies the water a bit, because it then explicitly calls the finalizer on a class, whereas it would normally be the GC that does it (and while calling GC-related functions in a finalizer is forbidden when called by the GC, it's fine when called via destroy, since the GC is then not in the middle of a collection). So, I don't know whether it would be reasonable to require that destructors be nothrow. Certainly, it's _more_ likely for it to be reasonable for destructors on classes to be nothrow, since classes always live on the heap (and are thus finalizers) unless you're playing games with something like std.typecons.scoped, but I'd have to study the matter quite a bit more to give a properly informed answer as to whether it would be reasonable to require that all destructors be nothrow. - Jonathan M Davis
Jun 04
next sibling parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Sunday, 4 June 2017 at 09:04:14 UTC, Jonathan M Davis wrote:

 if throwing in a destructor is considered a runtime error, 
 perhaps another valid enhancement would be to statically 
 disallow throwing Exceptions in destructors, i.e. *require* 
 them be nothrow?..
My initial reaction would be that destructors should always be nothrow, though I vaguely recall there being some reason why it was supposed to be nice that destructors in D could cleanly deal with exceptions. And remember that when we're talking about rt_finalize, we're talking about finalizers, not destructors in general. When a destructor is in a GC heap-allocated object, it's treated as a finalizer and may or may not be run (since the object may or may not be collected),
It doesn't matter. The only thing that matters is that it may be run, and therefore rt_finalize has to count on that. And it sort of does, at the moment, by assuming the worst possible combination of attributes. Problem is, with current language rules, it cannot be any other way, as the runtime doesn't carry any information about attributes of finalized object, or the context in which finalization takes place (i.e. is it within a safe function?), which, sadly, makes unsafe code silently executable in a safe context, in direct contradiction to language guarantees.
 whereas when a destructor is on an object that's on the stack, 
 it's really a destructor. So, while they use the same syntax,
It's worse than that. There are two "destructors": __xdtor that calls destructors of RAII members, and, on classes, __dtor that actually calls ~this() for the class. But only that class, not it's ancestors or descendants. Such segregation is, as it turns out, as useful as it is unwieldy.
 and in the case of a struct, the same function could be either 
 a destructor or a finalizer depending on where the struct is 
 declared, they're not quite the same thing. And destroy muddies 
 the water a bit, because it then explicitly calls the finalizer 
 on a class, whereas it would normally be the GC that does it 
 (and while calling GC-related functions in a finalizer is 
 forbidden when called by the GC, it's fine when called via 
 destroy, since the GC is then not in the middle of a 
 collection).

 So, I don't know whether it would be reasonable to require that 
 destructors be nothrow. Certainly, it's _more_ likely for it to 
 be reasonable for destructors on classes to be nothrow, since 
 classes always live on the heap (and are thus finalizers) 
 unless you're playing games with something like 
 std.typecons.scoped, but I'd have to study the matter quite a 
 bit more to give a properly informed answer as to whether it 
 would be reasonable to require that all destructors be nothrow.
Scoped is not necessary. Classes may not necessarily exist in the GC heap, thanks to custom allocators and emplace(). But because the language does not enforce propagation of destructor attributes, destroy() is system and not nothrow, which spills out into user code that would otherwise take advantage of static inference. Unfortunately, right now making it any other would impose certain restrictions on classes without real language support, and that is... scary.
Jun 04
prev sibling parent reply vit <vit vit.vit> writes:
On Sunday, 4 June 2017 at 09:04:14 UTC, Jonathan M Davis wrote:
 [...]
Why Nullable!T call destroy for reference types?
Jun 04
parent Jonathan M Davis via Digitalmars-d-learn writes:
On Sunday, June 04, 2017 09:31:24 vit via Digitalmars-d-learn wrote:
 On Sunday, 4 June 2017 at 09:04:14 UTC, Jonathan M Davis wrote:
 [...]
Why Nullable!T call destroy for reference types?
It calls destroy for everything. Why it does that instead of simply assigning T.init and setting _isNull to true, I don't know. Maybe the commit history would say, but unless it was done as part of a bugfix, it's more likely that you'd have to use the commit history to figure out who made it do that and ask them. Thinking about it though, it does seem like it's probably the wrong behavior. I'd guess that it was done with structs in mind, and it doesn't usually make sense to put a class reference in Nullable outside of generic code, since they can be null on their own. - Jonathan M Davis
Jun 04
prev sibling next sibling parent vit <vit vit.vit> writes:
On Saturday, 3 June 2017 at 06:19:29 UTC, Jonathan M Davis wrote:
 [...]
thanks
Jun 03
prev sibling parent reply Kagamin <spam here.lot> writes:
On Saturday, 3 June 2017 at 06:19:29 UTC, Jonathan M Davis wrote:
 Assigning Nullable!Test.init is equivalent to setting the 
 internal value to Test.init and setting _isNull to false.
Eh? Does it mean Nullable is default initialized to some non-null default value?
Jun 03
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Saturday, June 03, 2017 14:30:05 Kagamin via Digitalmars-d-learn wrote:
 On Saturday, 3 June 2017 at 06:19:29 UTC, Jonathan M Davis wrote:
 Assigning Nullable!Test.init is equivalent to setting the
 internal value to Test.init and setting _isNull to false.
Eh? Does it mean Nullable is default initialized to some non-null default value?
Well, that depends on what you mean by null. Nullable!T doesn't use pointers, so it can't be null like a pointer is null. The whole point of Nullable!T is to emulate the null behavior of pointers while keeping everything on the stack. It's a struct that contains two members: T _value; bool _isNull = true; So, _value is default-initialized to T.init, and _isNull defaults to true. Whether Nullable!T is "null" or not depends on the value of _isNull. So, Nullable!T is default-initialized to null in the sense that _isNull is true, and all of its member functions that check for "null" check whether _isNull is true, so it's treated as "null" when it's default-initialized, but it's not truly null in the sense that a pointer or class reference can be null. If that's what you want, just create a T* rather than a Nullable!T. - Jonathan M Davis
Jun 04
parent reply Kagamin <spam here.lot> writes:
On Sunday, 4 June 2017 at 08:51:44 UTC, Jonathan M Davis wrote:
 On Saturday, 3 June 2017 at 06:19:29 UTC, Jonathan M Davis 
 wrote:
 Assigning Nullable!Test.init is equivalent to setting the 
 internal value to Test.init and setting _isNull to false.
T _value; bool _isNull = true;
So it was a typo that Nullable.init sets _isNull to false?
Jun 05
parent Jonathan M Davis via Digitalmars-d-learn writes:
On Monday, June 05, 2017 10:46:39 Kagamin via Digitalmars-d-learn wrote:
 On Sunday, 4 June 2017 at 08:51:44 UTC, Jonathan M Davis wrote:
 On Saturday, 3 June 2017 at 06:19:29 UTC, Jonathan M Davis

 wrote:
 Assigning Nullable!Test.init is equivalent to setting the
 internal value to Test.init and setting _isNull to false.
T _value; bool _isNull = true;
So it was a typo that Nullable.init sets _isNull to false?
Yes. - Jonathan M Davis
Jun 05