On Sunday, 14 November 2021 at 01:15:06 UTC, Stanislav Blinov wrote:
> Indeed, forget allocation, given that I'm talking about collection. But anyway, so what? What do signals have to do with `new` pretending to be pure when it calls destructors that aren't?

A signal handler may not be pure, and it may be called at any time.  Including during the execution of a pure function.  Hence, your argument implies that no function should ever be marked as pure, because it may be interrupted by a signal handler which has some effects.

On Sunday, 14 November 2021 at 02:24:42 UTC, Elronnd wrote:

> A signal handler may not be pure, and it may be called at any time.  Including during the execution of a pure function.  Hence, your argument implies that no function should ever be marked as pure, because it may be interrupted by a signal handler which has some effects.

Yes, yes, and cosmic radiation may flip a bit in my CPU thus also mutate my state. I still don't see what that has to do with the language and its runtime.

On Sunday, 14 November 2021 at 02:54:52 UTC, Stanislav Blinov wrote:
> On Sunday, 14 November 2021 at 02:24:42 UTC, Elronnd wrote:
>
>> A signal handler may not be pure, and it may be called at any time.  Including during the execution of a pure function.  Hence, your argument implies that no function should ever be marked as pure, because it may be interrupted by a signal handler which has some effects.
>
> Yes, yes, and cosmic radiation may flip a bit in my CPU thus also mutate my state. I still don't see what that has to do with the language and its runtime.

Signals are part of the language.  Proof: GC must be able to hijack threads; so there must be some mechanism for preempting an existing thread of execution; and GC is part of the language.

Hence, that a function is 'pure' cannot be a strict indicator that, between the time it is called and the time it returns, no side effects are performed.

So it seems not at all inconsistent to me that a pure function may cause the GC to run, causing a destructor to be run.

On 11/12/2021 4:31 AM, Steven Schveighoffer wrote:
> One of the prerequisites to doing reference counting is to have a mutable piece of data inside an immutable piece of data.

Or maybe just give up on having immutable ref counted objects. Ref counted objects are mutable.

On 14/11/2021 8:16 PM, Walter Bright wrote:
> On 11/12/2021 4:31 AM, Steven Schveighoffer wrote:
>> One of the prerequisites to doing reference counting is to have a mutable piece of data inside an immutable piece of data.
> 
> Or maybe just give up on having immutable ref counted objects. Ref counted objects are mutable.

This isn't entirely true.

If all calls into reference counting have a known delta of zero, all calls in are elided therefore nothing changed.

const + scope + ARC has some very interesting possibilities here.

On 11/13/2021 11:16 PM, Walter Bright wrote:
> Or maybe just give up on having immutable ref counted objects. Ref counted objects are mutable.

Let me expand on that a bit.

This conversation reminds me of the old "logical const" debate, where people wanted to have constant objects that were not constant. That just would not work with the notion of transitive const.

Having a __mutable field in an immutable hierarchy is the same abomination. Attempting it immediately starts causing the rest of the type axioms in D to come apart. As Steven pointed out, sharing stops working.

It's like defining pi to be 3.0, and a right angle to be 89 degrees. Your house will not fit together if the corners are 89 degrees.

How does C++ manage it? They don't have immutable types. Const is just a documentation attribute.

How do functional languages do it? Reference counted types are not part of the type system. They are behind the curtain, just like how the gc works in D is behind the curtain, and associative arrays(!).

D has these choices:

1. ref counted objects are mutable

2. ref counted objects are outside of the type system

3. break the type system

I find (3) to be a bit ironic after D has been lambasted for having inconsistent semantic rules.

PS. I suspect that ref counted shared mutable objects are an indicator of insanity.

On 11/12/2021 11:16 AM, Steven Schveighoffer wrote:
> having immutable implicitly shared is stupid when it's obviously not. Like an immutable stack variable, why should I have to worry about sharability there? Should I even be able to share it with another thread, as the stack is easily destroyed?

Mutability and lifetime are orthogonal attributes.

On Sunday, 14 November 2021 at 08:29:33 UTC, Ola Fosheim Grøstad wrote:
> Thus pure functions are allowed to conduct I/O, albeit a primitive one.
>
> Note that a pure function also can prevent destruction merely by computing an integer that is aliasing an address of an object that is up for destruction. Again, primitive I/O. So clearly a side effect.

And a pure function can also conduct I/O by constructing a null pointer (or being passed one) and dereferencing it; and then doing the work in the SIGSEGV handler.

I don't think this makes pure functions less interesting or meaningful from a practical standpoint.