> 1. Supporting the ternary operator "?:" when "if" is already an > expression seems redundant.
As a compulsive code golfer, I'm kind of attached to ?: -- but the point about the '?' and ':' symbols being useful for other things is very valid (we're definitely running out glyphs). > 2. Inferring the type of 'x' in "let x = []" is neat, but is this type > of inference a privilege restricted to the builtin types? No. 'let x = none;' also works (and none is defined as a regular sum type in the stdlib). > 3. The subject says semantics but this is really a syntax objection. I > think "3 as float" will ultimately be a language wart Good call. I've been noticing this too -- there are a bunch of special cases in the parser and pretty-printer to work around this. Added to that, the low precedence on 'as' keeps surprising me. I'd be okay with using a different syntax -- though as<float>(3) seems overly ugly. > 4. target_os and similar attributes may seem convenient but I suspect > will have Rust biting off more than it can chew. What version of win32 > does target_os="win32" mean? It is possible for users to define and check against their own flags. I think there is no harm in providing some basic ones in the compiler. > 7. Not sure if this is intentional or an oversight: but it looks like > there's no way to extend a polymorphic data type while maintaining > independent compilation. We're trying to avoid subtyping. We're working on something akin to type classes, which might address your point here. > 8. Having a 'cycle collector' for shared box types seems as bad as > having a garbage collector. I don't know the details of our cycle collector, but I think we can statically determine which types *might* contain cycles, and only run it on those. Most programs won't have any cyclic types in them. > 9. I'm curious as to the justification for making log a builtin > keyword rather than a builtin library. There are plans to add some reflection features that would make it possible to implement log in the stdlib (and allow people to implement and use alternatives). Best, Marijn _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
