On 24.05.22 18:20, Walter Bright wrote:
> On 5/24/2022 12:43 AM, Timon Gehr wrote:
>> The original example no longer compiles, there are others in that thread. It has not been fixed!
> 
> Other issues should get their own bugzilla issue.

You are twisting my words. It's not another issue, it's another _example_. It's just that the pull request only fixed some special case.

But sure, not really worth arguing. Whether or not the 15 year old bugzilla issue remains open or is replaced by a new duplicate report does not change much.

On 24.05.22 19:10, Walter Bright wrote:
> On 5/24/2022 12:45 AM, Timon Gehr wrote:
>> No. The correct behavior when a delegate literal outlives captured variables is to allocate a closure. This case is not an exception...
> 
> But it isn't a safety problem, as it won't compile.

Well, it's still a memory safety problem in @system code, it's just that it's not a soundness issue for @safe.

On Tuesday, 24 May 2022 at 17:55:11 UTC, Walter Bright wrote:
> .. ....
> Everyone has their own must-have favorite enhancement request. Unfortunately, they're all different!

This is *not* a new dilemma in a free and open community.

This is why those who claim to represent the community, need to prioritse their focus on those things that are likely to meet the needs of the majority of the community.

Which is not saying you should not seek to meet the needs of the few.

But when you're focus is on the needs of the few, at the expense of the needs of the majority, well....as we here in Australia have just demonstrated (in our recent election).. we throw you out ;-)

On 24.05.22 07:00, Walter Bright wrote:
> On 5/22/2022 3:37 AM, Timon Gehr wrote:
>>>> Just on type qualifiers:
>>>>   - Transitivity of type qualifier doesn't play nice with template. There is no way to tell the compiler that a `const Tpl!T` actually is a `const Tpl!(const T)`. As a result, no container library is possible and ranges have serious problem when it come to qualifiers too.
>>>
>>> This needs a lot more fleshing out about what exactly is wrong and why.
>>> ...
>>
>> Instances of the same struct/class template are independent types without any relationship. Different types of slices (for example) are not.
> 
> Illuminating examples, please.
> ...

For containers: Just consider a struct wrapping a built-in slice.

struct Slice(T){
    T[] slice;
}

T[] is a subtype of const(T)[], but Slice!T is not a subtype of Slice!(const(T)). In general this cannot be guaranteed, but containers may need to be able to allow this kind of conversions.


For ranges:

E.g., here, x is a const slice and can be mapped. The resulting const value cannot be used as a range anymore.


```d
import std.algorithm;
void main(){
    const x=[1,2,3,4];
    const y=x.map!(v=>2*v); // ok
    const z=y.map!(v=>2*v); // error
}
```

This kind of thing should just work, but there is no way to strip away the topmost const for a MapResult.

(There is probably an unrelated Phobos bug as well, as the error happens in the guts of Phobos.)


> 
>> There is no way to declare a tail-immutable class reference.
>>
>> immutable(int)* <- can rebind the reference, can't assign to value
>>
>> immutable(Class) <- can't rebind the reference
>> Class <- can rebind the reference, can assign to value
> 
> Should file an Enhancement Request on Bugzilla.

There's e.g. this one: https://issues.dlang.org/show_bug.cgi?id=5325

On Tuesday, 24 May 2022 at 22:45:50 UTC, Timon Gehr wrote:
> But sure, not really worth arguing. Whether or not the 15 year old bugzilla issue remains open or is replaced by a new duplicate report does not change much.

We should probably re-open all the other issues that were marked duplicates of this one then, since there's plenty of other examples in there that do still compile without modifications.

And I'd point out the original example fails to compile for the wrong reason. So it isn't like it is actually fixed at all.

On 5/24/2022 3:45 PM, Timon Gehr wrote:
> On 24.05.22 18:20, Walter Bright wrote:
>> On 5/24/2022 12:43 AM, Timon Gehr wrote:
>>> The original example no longer compiles, there are others in that thread. It has not been fixed!
>>
>> Other issues should get their own bugzilla issue.
> 
> You are twisting my words. It's not another issue, it's another _example_. It's just that the pull request only fixed some special case.
> 
> But sure, not really worth arguing. Whether or not the 15 year old bugzilla issue remains open or is replaced by a new duplicate report does not change much.

If the fix did not fix other cases, then they are separate bugs. They certainly may be related, but if they require more code, they are separate.

Our whole use of github and bugzilla revolves around a 1:1 correspondence between bug fixes and PRs. A 1:many and many:1 is just not manageable.

On 25.05.22 00:55, Timon Gehr wrote:
> On 24.05.22 19:10, Walter Bright wrote:
>> On 5/24/2022 12:45 AM, Timon Gehr wrote:
>>> No. The correct behavior when a delegate literal outlives captured variables is to allocate a closure. This case is not an exception...
>>
>> But it isn't a safety problem, as it won't compile.
> 
> Well, it's still a memory safety problem in @system code, it's just that it's not a soundness issue for @safe.

Actually, that's not even true. The line that does not compile does not even have to do anything with the issue. This compiles even with -dip1000:

```d
import std.stdio;

void main()@safe{
    void delegate()@safe[] dgList;
    foreach(i; [1, 2, 3]) {
        immutable b = i;
        dgList ~= { writeln(b); };
    }
    foreach(dg; dgList) dg();
}
```

I.e., this issue is alive and well. It's a memory safety issue in @system code and it's a soundness problem for @safe.

On Tuesday, 24 May 2022 at 20:36:52 UTC, Walter Bright wrote:
> On 5/22/2022 6:31 AM, deadalnix wrote:
>> The problem here isn't that people aren't reporting these, or aren't writing DIP or whatever. It is that they are told to do so, waste their time doing that and then they get named argument instead.
>
> I did a bugzilla search for every issue you have submitted:
>
> https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&email1=deadalnix&emailreporter1=1&emailtype1=substring&list_id=240739&query_format=advanced&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=LATER&resolution=REMIND&resolution=DUPLICATE&resolution=WORKSFORME&resolution=MOVED
>
> Every single one was resolved.
>
> You are not wasting your time posting issues.
>

When I report bug, they get fixed and it's great.

When I report design problem, they get treated as bugs and we never get to the root of the issue and I'm wasting my time.

On 5/24/2022 4:21 PM, Timon Gehr wrote:
> For containers: Just consider a struct wrapping a built-in slice.
> 
> struct Slice(T){
>      T[] slice;
> }
> 
> T[] is a subtype of const(T)[], but Slice!T is not a subtype of Slice!(const(T)). In general this cannot be guaranteed, but containers may need to be able to allow this kind of conversions.

What about:

    struct Slice(T) { T[] slice; int* p; }

? A const applied to T will not affect int*, but if the const automatically was transferred to Slice, it would, and that would be wrong. It seems you're asking for a special case, and as we all lament, special cases lead to corner cases with special problems.


> For ranges:
> 
> E.g., here, x is a const slice and can be mapped. The resulting const value cannot be used as a range anymore.
> 
> 
> ```d
> import std.algorithm;
> void main(){
>      const x=[1,2,3,4];
>      const y=x.map!(v=>2*v); // ok
>      const z=y.map!(v=>2*v); // error
> }
> ```
> 
> This kind of thing should just work, but there is no way to strip away the topmost const for a MapResult.

const(int**) p;
cast()(p) produces a const(int*)*

I.e. cast() strips the "head" qualifiers.



>>> There is no way to declare a tail-immutable class reference.
>>>
>>> immutable(int)* <- can rebind the reference, can't assign to value
>>>
>>> immutable(Class) <- can't rebind the reference
>>> Class <- can rebind the reference, can assign to value
>>
>> Should file an Enhancement Request on Bugzilla.
> 
> There's e.g. this one: https://issues.dlang.org/show_bug.cgi?id=5325

thank you

On 5/24/2022 3:55 PM, Timon Gehr wrote:
> On 24.05.22 19:10, Walter Bright wrote:
>> On 5/24/2022 12:45 AM, Timon Gehr wrote:
>>> No. The correct behavior when a delegate literal outlives captured variables is to allocate a closure. This case is not an exception...
>>
>> But it isn't a safety problem, as it won't compile.
> 
> Well, it's still a memory safety problem in @system code, it's just that it's not a soundness issue for @safe.

The whole point of @system is to remove the safety checks.

I'm more interested in soundness than in replicating closure semantics of other languages. Especially since the workarounds are simple:

Replace `int x` with `int* px = new int()`

I.e. one can always make a closure manually. It's not the end of the world if the compiler doesn't provide a spoonful of sugar for it.

Don't get me wrong, I'm still interested in adopting good semantics from other languages, it's just that soundness is much more of a priority.

I do enjoy and appreciate your contributions, too, even if it seems like I'm always arguing with you :-/