On 7/6/18 11:22 AM, Timoses wrote:
On Friday, 6 July 2018 at 14:28:39 UTC, Steven Schveighoffer wrote:
inout is not a compile-time wildcard, it's a runtime one. So it
doesn't know how to convert an immutable to an inout. Essentially,
inside this function, the compiler has no idea whether the real thing
is an immutable, const, mutable, etc.
The fix is simple, replace both your constructors with one inout
constructor:
this(inout(S) t) inout { this.s = t; }
Slowly getting acquainted to inout... Feels like magic.
I'm long overdue for an inout article...
I can point you at my talk from 2016:
https://www.youtube.com/watch?v=UTz55Lv9FwQ
"viral" is very fitting. Throw in pure and I quickly reach the bottom of
my program hitting a library function I used which is not pure.
I never really used 'pure' and just now found a use case with immutable
[1], i.e. to return unique objects from functions which can be assigned
to a mutable or immutable reference.
What other "use cases" or reasons to use 'pure' are there (aside from
compiler optimizations)?
The reason pure functions allow mutability changes is due to the nature
of what pure means semantically -- you have guarantees that nothing else
goes in or out, so it's possible to deduce what is unique and what is not.
This is powerful to a human reader of a function as well! Without seeing
the insides, it tells you exactly what it can and cannot affect, giving
you more understanding of when it can be used and when it can't. It
helps write safer more tractable code, IMO.
In the end, all these attributes are to help reason about large code
bases without having to read ALL the code.
-Steve
