I think you underestimate the impact of this change---flipping the
default is easy, but dealing with the repercussions, particularly as
regards self-hosting, is not. That said, now that we have agreed to
attempt the write barrier plan (sometimes called INHTWAMA, after this
blog post [1]), it is very likely that the distinction between pure and
impure fns will go away entirely.
Niko
[1]
http://www.smallcultfollowing.com/babysteps/blog/2012/11/18/imagine-never-hearing-the-phrase-aliasable/
Andres G. Aragoneses wrote:
On 26/11/12 17:51, Graydon Hoare wrote:
On 12-11-26 08:11 AM, Andres G. Aragoneses wrote:
Hello,
I just wanted to know the rationale behind the decision about having a
"pure" keyword instead of an "impure" one (in the same way, the analogy
here is that there is an "unsafe" keyword, not a "safe" one).
The decision is an old one related to a time when we had a full effect
system and typestate system: the definition was too strong to meet in
most cases and wound up requiring 'impure' (at the time, spelled 'io')
annotations on nearly every function in normal code. It is no longer
strongly justified by those reasons, imo,
Then, with the aim of avoiding Perfect being the enemy of Done, would
a pull-request from an external contributor that flipped this two (to
make pure be the default) be accepted?
(It's just that this small room for improvement seems the only blocker
for me to take a serious look at Rust. So I feel I could manage to
create a patch to inverse the default purity, but of course I could
not manage any simplification over this because I've never looked at
rust's implementation and likely won't have enough time to figure out.)
but I suspect any change to it
now would be accompanied by an attempt to simplify the relationship
between borrowing and purity altogether (it's a bit unintuitive
presently). I expect there may still be some reform in this area, though
the details are mostly in the heads of others presently.
Those with the upcoming changes in their head would still be able to
simplify things, but dealing with the "impure" keyword instead of the
"pure" one.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
