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.
scope
on a struct variable makes all fieldsscope
. This came up when making a tokenizer range: When parsing a stack-allocated string, the resulting tokens also becomescope
even when they don't refer to the input string.
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`
}
- Scope inference on assignment doesn't remember the original lifetime, but shortens it to the assigned variable.
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
}
- 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.