immutable / inout / pure headaches

[Timoses]

On Friday, 6 July 2018 at 15:44:28 UTC, Steven Schveighoffer 
wrote:
>
> I'm long overdue for an inout article...
>
> I can point you at my talk from 2016: 
> https://www.youtube.com/watch?v=UTz55Lv9FwQ
Thanks, will definitely take a look when I get home.
>
>> 
>> 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.

Sounds like a good idea to always use it whenever possible. For 
me as a kind of novice it takes time to understand the purpose 
and meaning of each of those attributes. I guess I got one step 
closer to understanding "Why pure?".

That leaves @nogc, @safe and @trusted :D. I feel the best way to 
understand these idioms is to experience the "trouble" oneself. I 
knew in some way what pure functions were from the spec, but I 
didn't have an example at hand that made "non-usage" of pure 
painful.