Manu: > what would there be to verify or enforce in this case?
There are type system features like memory zones, linear types, uniqueness typing, and so on, that are able to enforce similar invariants. D lacks those type system features, so it can't enforce that a restricted pointer is actually unique. D Zen seems to not appreciate annotations that can't be enforced (this is not a hard rule). This is one of the possible explanations for the lack of @restrict. > How difficult is it to contribute to D in these areas? There are contributors that write more than one compiler patch (pull requests in GitHut) every week, and they often get merged in the main compiler, especially when they are good, and their need is "obvious" or it was already discussed in the D newsgroups and accepted. It's not easy to write good compiler patches, but it's clearly doable if you are good. > Is that something > that is encouraged, or is D still too embryonic to have random people coming > along and adding things here and there? There are a large number of open bugs in Bugzilla, front-end bugs too, so creating pull requests/patches that fix them is encouraged. Even some small enhancement requests, when they are clearly good and they are backwards compatible, are often accepted. Breaking changes are less easily accepted, they probably require a precedent discussion in D newsgroups. Regarding significant enhancement pull requests (like adding a @restrict, or like this one: https://github.com/D-Programming-Language/dmd/pull/3 that is sleeping there for a lot of time), they need discussion first, and are accepted slowly, and not surely. Bye, bearophile
