> On Wed, Apr 3, 2013 at 6:44 PM, Matthieu Monrocq > <[email protected]> wrote: > > Well, a full effect system might not be necessary "just" for safe plugins. > > Since we have a way in Rust to indicate which version a "plugin" we want > to link to, we could apply some restrictions there. > > For example, specifying that only a certain list of other libraries can be > used by this "plugin" (and typically none with IO features) and that it > cannot use unsafe code would guarantee some sandboxing already. Similarly, > the GC restriction could be placed there. > > On Wed, Apr 3, 2013 at 1:22 PM, Grant Husbands <[email protected]> wrote: > I've now read through the mentions of effect systems and indeed I am talking > about something simpler that doesn't require either function granularity or > inference. As Matthieu Monrocq notes it mostly amounts to restrictions of > imports and probably parse-time restriction of particular constructs over a > whole module/plugin. > > I'm willing to create a demo/fork for it, but I wouldn't want to waste > effort if it's something that wouldn't be accepted. If it's to be added at > all, it might be best to add it for 1.0, so as to reduce the amount of code > written without it in mind.
This seems like a great use-case for compiler plugins, which, unless I'm getting my languages mixed up, Rust has plans to support? I think people will have all sorts of ideas for static passes they want to perform during a build, and plugins would let them easily be tested (on travis-ci even, say) by the community without tracking an internal API. Re: safe libraries, I think even just a conventional manifest/description of some kind would be fine; if you mark your library as "safe, doesn't do X, Y, or Z" and you're wrong, well, the community will let you know. It doesn't have to necessarily be deep compiler / effect system magic, to me. --Wilson. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
