Tell us your DIP1000 woes

[Dennis]

On Sunday, 25 August 2024 at 13:10:22 UTC, Mike Parker wrote:
> Second, we'd like to get a number of examples of problems 
> people have had with using DIP1000 that haven't shown up in 
> Bugzilla.

1. `scope` on a struct variable makes all fields `scope`. This 
came up when making a tokenizer range: When parsing a 
stack-allocated string, the resulting tokens also become `scope` 
even when they don't refer to the input string.

```D
class Token {}

struct Tokenizer
{
     char[] input;
     Token front;
}

Token getToken() @safe
{
     char[5] input = "1 + 2";
     auto range = Tokenizer(input[]); // range as a whole becomes 
`scope` here
     return range.front; // Unnecessary error that `range.front` 
is `scope`
}
```

2. Scope inference on assignment doesn't remember the original 
lifetime, but shortens it to the assigned variable.

```D
struct S
{
     string name;
     void doSomething() scope;
}

void f(scope S s)
{
     string prev = s.name; // prev simply becomes `scope`, doesn't 
remember it came from `s`
     s.doSomething();
     s.name = prev; // Unnecessary error: `prev` assigned to s 
with longer lifetime
}
```

3. Lack of transitive scope

I.e. you can't have an array of stack allocated strings, or a 
hashmap using scope keys/values. There are workarounds. For 
example, in my regex match function, I return indices of matches 
instead of slices of the input string. This does make the API a 
lot less ergonomic though.