https://issues.dlang.org/show_bug.cgi?id=20010

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--

https://issues.dlang.org/show_bug.cgi?id=20010

Bolpat <qs.il.paperinik@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |qs.il.paperinik@gmail.com

--- Comment #1 from Bolpat <qs.il.paperinik@gmail.com> ---
I’d be in favor of the cast.

Grammar:
```diff
    CastQual:
-       cast ( TypeCtors? ) UnaryExpression
+       cast ( MemberFunctionAttributes? ) UnaryExpression
+       cast ( ... MemberFunctionAttributes ) UnaryExpression
+       cast ( ! ...[opt] MemberFunctionAttributes ) UnaryExpression
```

Note that `MemberFunctionAttributes` includes `TypeCtors`.

Semantics of `cast()` must remain so that it only removes `TypeCtor`s. To
remove other things, either use e.g. `cast(@system)` or fix
https://issues.dlang.org/show_bug.cgi?id=24587.

One issue I see, however, is with delegate types: `cast(immutable)` would
produce `immutable(R delegate())` and there’s no way to go from `R delegate()`
to `R delegate() immutable` with a cast. This is what the second rule does: It
applies the member function attribute to the function type even if it’s a type
qualifier.

`cast(pure)` is unambiguous, so it doesn’t require `cast(... pure)`, but
`cast(... pure)` should be legal. The `...` essentially becomes
`typeof(UnaryExpression)`.

As for Issue 24587 (negated forms), that’s the last rule: `cast(! ... const)`
removes `const` as a member function attribute.

--