Keep in mind that Rust's type system offers very strong guarantees about aliasing which I think will be very helpful for this sort of optimization. For example:
- `&T` data is *immutable* (not const) - all `&mut` are disjoint (i.e., ANSI C's `restrict`, but checked and by default) - when an `@mut` is modified, there can be no aliases at that time - maybe more? The presence of unsafe code does complicate matters. One important guideline will be to establish what invariants unsafe code must maintain to avoid straying into "undefined behavior" land. Niko On Tue, Apr 30, 2013 at 10:31:32AM -0700, Max Cantor wrote: > In Haskell they're spectacularly useful. For example, implementing STM in > about a weekend as opposed to never: > http://blog.enfranchisedmind.com/2009/01/the-problem-with-stm-your-languages-still-suck/ > > I know STM doesn't necessarily play with the Rust memory model, just an > example of an unexpected capability that emerged from having pure functions. > > > On Tue, Apr 30, 2013 at 10:23 AM, Gregory Maxwell <[email protected]>wrote: > > > On Tue, Apr 30, 2013 at 10:08 AM, Max Cantor <[email protected]> wrote: > > > I know this will be an unpopular opinion, but pure functions would be a > > > massive win for Rust, especially if the eventual goal is high > > performance, > > > highly parallelizable (browser rendering engines..) development. > > > > Being able to annotate a function as side-effect free (e.g. via > > __attribute__ ((pure)) in GCC) can yield some useful optimizations, > > but I expect that LTO largely makes it unnecessary. The pure > > attribute in GCC in C is not checked and can result in bugs, but I > > think it's also not widely enough used in C that there is a lot of > > practical experience with bugs resulting from the misuse. At times I > > know I've wished the annotation were more widely used just because it > > would make reasoning about third party code easier: "does foobar() > > have non-trivial side effects???" > > > > I understand that D has checkable pure functions I'm not sure how > > useful they've been there. I recall hearing that there were some > > gnarly interactions with heap allocation. > > > _______________________________________________ > 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
