https://issues.dlang.org/show_bug.cgi?id=19065

FeepingCreature <default_357-line@yahoo.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal

--

https://issues.dlang.org/show_bug.cgi?id=19065

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |safe
                 CC|                            |bugzilla@digitalmars.com
           Hardware|x86_64                      |All
                 OS|Linux                       |All
           Severity|normal                      |enhancement

--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> ---
I think this change defeats the purpose of having an invariant. T.init is supposed to be a valid object, and so should pass the invariant.

It's not a bug, it's the way the language is designed to work.

To make this modification to the semantics, a fairly compelling use case will be required.

--

https://issues.dlang.org/show_bug.cgi?id=19065

--- Comment #2 from FeepingCreature <default_357-line@yahoo.de> ---
T.init having to be a valid object makes structs unusable for value types that contain objects by reference that must not be null, or arrays that must not be empty. At my workplace, this scenario turns up a *lot* when trying to use structs to contain domain data.

--

https://issues.dlang.org/show_bug.cgi?id=19065

--- Comment #3 from FeepingCreature <default_357-line@yahoo.de> ---
That said, the only case "invariant on destruction" even comes up, is when changing values via public fields and using the destructor as a kind of "last-ditch invariant check", which imo is largely useless because one by definition you haven't called domain methods on it anyway, and two - if T.init is supposed to be valid, you have to recheck all references for null in the destructor *anyways*, since you can't have the checks in the invariant.

The only thing that having to have T.null be a valid object buys you is making it impossible to use invariant for null checks. As far as I can see, the userland code ends up strictly, necessarily more awkward by that rule.

--

https://issues.dlang.org/show_bug.cgi?id=19065

Ali Ak <ali.akhtarzada@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ali.akhtarzada@gmail.com

--- Comment #4 from Ali Ak <ali.akhtarzada@gmail.com> ---
(In reply to Walter Bright from comment #1)
> I think this change defeats the purpose of having an invariant. T.init is supposed to be a valid object, and so should pass the invariant.
> 
> It's not a bug, it's the way the language is designed to work.
> 
> To make this modification to the semantics, a fairly compelling use case will be required.

Does this mean the compile time constructed value of T must be a valid runtime constructed value of T to be able to use invariants?

--

https://issues.dlang.org/show_bug.cgi?id=19065

--- Comment #5 from FeepingCreature <default_357-line@yahoo.de> ---
Yep.

--

https://issues.dlang.org/show_bug.cgi?id=19065

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--

https://issues.dlang.org/show_bug.cgi?id=19065

--- Comment #6 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/19455

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--