On 10-08-28 02:33 PM, Sebastian Sylvan wrote:
Let me first say that the only reason I write this is because I really like
Rust. It seems to get a lot of things really right, and I'd like it to
become successful! With that said, here's one issue. I have more, and I may
write more about that later, but I figured I start with this one because it
actually ends with a suggestion!
Hi,
First, I'd like to remind you of the conduct guidelines for this
community. While not quite venturing into the "abusive" or "flaming"
category, for an introductory post/proposal your tone is needlessly
provocative and filled with loaded terminology ("hijacking", "kludge",
"severely crippled"). We aim for decorum here, please try to respect
that. I had to rewrite my response a few times to ensure that I was not
escalating the tone, and I don't enjoy spending work hours on such
exercises.
With respect to the technical feasibility of your proposal: it may be
possible -- it's similar to how we currently translate foreach blocks,
for example -- and I'll add a note about this proposal to the existing
bug (issue #6) that's a work-item for a "lambda" short-form of anonymous
function immediate. If anyone wants to take the time to work out how
your proposal interacts with Rust semantics in more detail and ensure
it'd be safe, I'd be happy to entertain that conversation. Such
alias-based, scoped capture would have the pleasant additional benefit
of being faster than function bindings (no heap allocation), so I'm sure
nobody would object to trying to fit them in.
Finally, I should clarify some misconceptions in your post. When I speak
in the collective voice "we" here, I am referring to myself mainly as
well as some opinions I believe to be shared with others who have worked
on the Rust design. Please, others, speak up if you disagree:
- Comprehensibility is an important design goal in Rust, so we're not
terribly interested in appeals to "many" kinds of additional control
flow abstraction. Control flow is a notorious comprehension hazard
in code at the best of times. We may be interested in handling some
well-motivated cases we currently do poorly (at the moment, for
example, parallel iteration can't be done easily) as well as general
abstractions that support >1 of those. Hypothetical use-cases, much
less so.
- Rust has very few nonlocal control mechanisms already. Catchable
exceptions as outlined in your example are not something we consider
particularly plausible in Rust, due to custom typestate predicates
(there's a FAQ entry). Currently there is no such feature. Aside
from termination-semantics failure and loop-break / loop-continue,
there are no other nonlocal jumps, and (at the moment) not much
interest expressed in adding any.
- Destructors and RAII are not a "kludge", and try/finally blocks are
not a particularly good replacement for them. Destructors and RAII
encapsulate the initialization state of a resource and its
sub-resources, such that only those resources acquired wind up being
released. To mimic this in try/finally blocks is verbose and
error-prone: you need a boolean "tracking variable" for each
acquired resource that you set immediately after the resource is
acquired, as well as logic at the finally-side to conditionally
release only those resources acquired (and such logic is
order-sensitive, and needs its own try/finally blocks in order to be
as robust as a good destructor system). This is particularly
error-prone since you only notice coding errors in such paths in the
(rare) cases of exceptions actually being thrown; more likely, only
non-throwing case is exercised and the errors are shipped
un-noticed.
In addition, destructors and RAII generalize to handle resources
that outlive a control frame, without any change to the underlying
resource-manager object. Our feeling is therefore that destructors
and RAII are, on balance, a more-desirable feature than try/finally
blocks would be (if we had them).
If you have further concrete suggestions about changes to Rust, we'd be
happy to hear some of them as well, but please try to keep the tone
respectful and constructive. The (relatively interesting, reasonable)
proposal in your post was almost lost amid the paragraphs of additional
critique.
Thanks,
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
