I just realized that what I proposed earlier is pretty much exactly what predicate functions were in the days of typestate (sorry, I'm a bit new here). I completely understand and agree with the decision to remove typestate which does seem quite complex, however, predicate functions have a lot of value beyond typestate.
So, my questions are, did Predicate Functions themselves introduce a high degree of complexity? If not, would the community be open to bringing them back? If so, I'd be willing to put some work into doing that. On Tue, Apr 30, 2013 at 10:51 AM, Max Cantor <i...@cantor.mx> wrote: > If so, I had no idea. However, if it doesn't come in before 1.0 then I > fear that ecosystem will develop around not having one and then by 2.0 it > will be "too late" > > > On Tue, Apr 30, 2013 at 10:49 AM, Gábor Lehel <illiss...@gmail.com> wrote: > >> On Tue, Apr 30, 2013 at 6:57 PM, Tim Chevalier <catamorph...@gmail.com>wrote: >> >>> On Mon, Apr 29, 2013 at 9:30 PM, Erik S <sw...@earthling.net> wrote: >>> > On 4/29/2013 2:00 PM, Graydon Hoare wrote: >>> >> Yes. Formalizing and completing the definition of the constant >>> >> expression subgrammar would be extremely valuable. It's one of the >>> >> major high-risk areas remaining the the design space. -Graydon >>> > VHDL is a very different language from Rust (it's a hardware design >>> > language, not a normal programming language), but it has the nicest >>> > constant system I've worked with. >>> > >>> > The rule is basically that constant expressions can contain: >>> > >>> > Literals (i.e. 5, 0x20) >>> > Expressions that depend on constants (i.e. 0x5 + 10 * const_k) >>> > Any "pure" function whose arguments are constant. (i.e. 5 + f_pure(5, >>> > const_k) ) >>> > >>> > It's this last rule that is truly beautiful. You can use the same >>> > functions in both constant initialization and run-time code, with only >>> > the requirement that they are pure. Pure functions are ones whose >>> output >>> > depends only on their arguments (and constants). Allowing functions to >>> > initialize constants avoids the whole annoyance in C/C++ where you have >>> > to use macros to make things compile-time const. It also allows a >>> > surprising amount of compile-time optimization. >>> > >>> > I don't know how realistic this is for constants in a language like >>> rust >>> > - but it would be very elegant if it could work. >>> > >>> >>> We used to have a notion of pure functions in Rust, but that was >>> removed recently. It originally existed for typestate (a feature we >>> removed a while ago) and more recently to assist the borrow checker. >>> We removed it because in Rust, it was impractical to define an >>> easily-checkable pure subset of the language. Bringing it back in is >>> somewhat less likely than adding significant whitespace. >>> >>> Cheers, >>> Tim >>> >> >> I thought an effects system (encompassing purity) is something that was >> vaguely planned for 2.0? >> >> >>> >>> >>> >>> -- >>> Tim Chevalier * http://catamorphism.org/ * Often in error, never in >>> doubt >>> "Too much to carry, too much to let go >>> Time goes fast, learning goes slow." -- Bruce Cockburn >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev@mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> >> >> >> -- >> Your ship was destroyed in a monadic eruption. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
