Change regarding invariant-noncompilant .init values

[dukc]

See https://forum.dlang.org/post/ohohfaisyaregskmkzme@forum.dlang.org

[dlang-bot]

Thanks for your pull request and interest in making D better, @dukc! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

[dukc]

If you disagree, see #2410 instead

[FeepingCreature]

Note that the invariant is not checked on access to .init at the moment, probably because it would be both hard to do (since .init is usually a constant) and pointless (since .init usually violates invariants). My impression was that .init would in fact silently violate invariants, but that this was acceptable because the generated values were still "basically safe", ie. valid or null.

edit: On the other hand, opening yourself to crashing bugs on null pointer access of course, which @safe ostensibly prevents...

So I don't disagree per se; I'm just saying this entails a compiler change.

edit: More interesting notes: if a struct with invalid .init has both a destructor and an opAssign, and the fields being validated in the invariant are private, then the use of .init invariably leads to an assert failure, either on destruction of the inited value, on assignment of a different value or on the next method call.

[jmdavis]

Strictly speaking, the invariant is called after a constructor is completed, before and after public functions are called and before the destructor is called. T.init itself never triggers the invariant, because no functions are called. IMHO, what you're saying here confuses matters considerably.

It would be far better to say something like "Default initialization does not trigger the invariant as no functions are called during default initialization."

[FeepingCreature]

The problem is the asymmetry: the invariant is not called on T foo = T.init;, but it is called on scope exit of foo.

[dukc]

As FeepingCreature said, non-invariantcompliant only make sense when you are not going to change the value at all, because a change would trigger the invariant first. But even that does not make sense when there is the destructor, which inevitably also triggers the invariant. Either making init values always checked or disabling checks before the destructor would solve the problem.

But I just realised my option here would mean code breakage. The disadvantage of the other option is that it closes the future possibility of removing the check before a function call, unless we allow doing work on .init value which does not satisfy the invariant. But I believe preventing code breaking is more important, so I'll close this in few days unless someone objects.

EDIT: another option is deprectating instantiating .inits with invalid values. The compiler could use CTFE to determine if the .init value satisfies invariants and to drop deprectation notes accordingly.

[jmdavis]

The problem is the asymmetry: the invariant is not called on T foo = T.init;, but it is called on scope exit of foo.

Honestly, I don't see any problem with that. If you understand how an invariant works, then you can code accordingly. The key issue as far as updating the spec goes is ensuring that it's clear. Also, checking the invariant after default initialization is kind of silly given that it's always going to be the same value, and if there were any problem with its invariant, then it would fail as soon as you called any functions on it. And honestly, from a strictly pedantic point of view, having an invariant that fails for T.init is in violation of the concept of an invariant anyway, since it's always supposed to be true for a value of type T. That can be annoying in some cases just like it can be annoying sometimes that we don't have default constructors in D, but having T.init comes with its own set of advantages, so it's a matter of pros and cons.

Regardless, if you want to argue about why the current behavior should be changed and write a DIP about it, then that's fine, and we may very well end up with something better as a result, but that's a completely separate issue from updating the spec. If the spec isn't clear enough about how the language currently works, then we can update it to clarify it, but a DIP is required if you actually want to change the semantics of the language.

[FeepingCreature]

I disagree fundamentally with both your points, but this is probably not the place, yeah.

Are you on IRC or Discord? This might be easier to work out in conversation.

That said, I'll probably just work around it with union.

edit: "Deprecating inits with invalid values" is in effect equivalent to either "deprecating struct invariants", or "deprecating structs for domain data, period."

[dukc]

I said: deprecating instantiating invalid .init values, not deprecating structs that have an invalid .init value. So the final behaviour after deprecation period would be exactly as described in this PR.

[dukc]

Closed as I promised.