Bug 23664 – Infer `const` for lambdas/closures

Status
NEW
Severity
enhancement
Priority
P4
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2023-02-02T14:20:45Z
Last change time
2024-12-13T19:27:01Z
Assigned to
No Owner
Creator
Bolpat
Moved to GitHub: dmd#20222 →

Comments

Comment #0 by qs.il.paperinik — 2023-02-02T14:20:45Z
Attributes (`@safe`, `pure`, etc.) are inferred for lambdas, but a delegate can also specify a type constructor (or a combination such as `inout const`). Because the implementation of the lambda is always known, the compiler can figure out if the delegate is in fact * `immutable`, i.e. all data it accesses through its context (if any) is `immutable`. * `const`, i.e. all the accessed data in its context (if any) is not changed by the delegate (think of: the delegate only calls free functions and `const` member functions on things it accesses). Note that type constructors in this case are purely additional information, the same way `@safe`, `pure`, `nothrow`, or `@nogc`. This means that forgetting them won’t make using the delegate invalid; only the context it’s used in might require them. (This requires that the implicit conversion of `immutable` to `const` and `immutable`/`const` to mutable for delegate context type constructors is implemented.
Comment #1 by robert.schadek — 2024-12-13T19:27:01Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/20222 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB