Uh... destructors?

[Bruno Medeiros]

On 08/03/2011 20:17, Steven Schveighoffer wrote:
> On Tue, 08 Mar 2011 14:28:44 -0500, Bruno Medeiros
> <brunodomedeiros+spam at com.gmail> wrote:
>
>> On 23/02/2011 17:47, Steven Schveighoffer wrote:
>>> On Wed, 23 Feb 2011 12:28:33 -0500, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>>> On 2/23/11 11:16 AM, Steven Schveighoffer wrote:
>>>
>>>>> Just because a function is not marked @safe does not mean it is
>>>>> unsafe.
>>>>> It just means you can do things the compiler cannot verify are
>>>>> safe, but
>>>>> that you know are actually safe. I showed you earlier an example of a
>>>>> safe pure function that uses malloc and free.
>>>>>
>>>>> Programmers are allowed to make conceptually safe functions which are
>>>>> not marked as @safe, why not the same for pure functions?
>>>>>
>>>>> -Steve
>>>>
>>>> I understand that. My point is that allowing unsafe functions to be
>>>> pure dilutes pure to the point of uselessness.
>>>
>>> And that's not a point. It's an unsupported opinion.
>>>
>>> pure has nothing to do with safety, it has to do with optimization. Safe
>>> functions are no more optimizable than unsafe ones. Safety has to do
>>> with reducing memory bugs.
>>>
>>> The two concepts are orthogonal, I have not been convinced otherwise.
>>>
>>> -Steve
>>
>> pure has something to do with @safety. (Also, it has more to do with
>> than just optimization, it also affects code readability.)
>>
>> In order to gain any benefit from calling pure functions (whether the
>> benefit is programmer code readability or compiler optimization) it
>> needs to be determined from the pure function's signature what is the
>> transitively reachable mutable state that the function may access.
>> Normally this state is whatever is transitively reachable from the
>> parameters. However, if you allow *arbitrary* _pointer arithmetic_ you
>> could legally manipulate any mutable data in your program from within
>> the pure function. This would make the pure attribute useless because
>> it would not offer any additional guarantees whatsoever over an unpure
>> function. So such a rule is necessary such that, for example, the
>> following function should not be allowed to be pure:
>>
>> pure int func(int* ptr, int ix) {
>> return (ptr + ix)++;
>> }
>
> If I want to make my own array type, then it will be quite unusable in
> such pure functions.
>

That was just a synthetic example, to show my point. Sure, here we could 
replace the parameters with an array, and then the compiler would be 
able to understand the semantics behind it, and thus also determine the 
actual possible transitive state (which would be the contents of the array).
But there are other situations where such would not be possible.

> Assuming that such code is illegal assumes the compiler fully
> understands the semantic meaning of that code.
>
> Keep in mind that an array is semantically understood by the compiler,
> but I can't convey that same semantic knowledge to the compiler for my
> custom type. I may know that some pointer arithmetic is perfectly safe
> and pure, even when the compiler cannot grok that. It doesn't make sense
> that pure functions shouldn't be allowed to be streamlined/optimized as
> I can normal functions. To me the concepts of @safe and pure are still
> orthogonal.
>

I'm not saying all pointer arithmetic and manipulation should be 
illegal. It could be allowed, but only so long as the coder maintains 
the contract of the pure attribute. So this means that you could use 
pointers to manipulate whatever is transitively reachable from the 
function parameters (or stuff that was created inside the pure 
function), but the rest should not be accessed through pointer 
arithmetic, precisely because the compiler would not be able to 
determine that from the function signature.
Note that when I said "illegal" I didn't necessarily mean compiler 
verified illegal code. That might be too complex to implement in the 
language, so instead it might just be a unchecked contract. Breaking 
that contract would result in /undefined behavior/.


> @safe is not so much about "safety" as it is about "compiler-verified
> safety". I feel somewhat the words are getting in the way here. I don't
> mean memory unsafe code, I mean memory safe code that cannot be compiler
> verified via @safe. I feel that because the compiler can't verify pure
> functions are memory safe doesn't make pure functions unusable or useless.
>
> -Steve

Yes, I am feeling we are getting a bit confused by words. Although I 
think I understood what you meant by unsafe code: legal code that cannot 
be verified by the compiler to be "@safe". The only other alternative 
(other than @safe code, is simply illegal code, in the runtime sense: 
aka, code that results in /undefined behavior/).

-- 
Bruno Medeiros - Software Engineer