> templates without concepts Traits aren't really any simpler than this. Templates don't produce nice errors and require the type checker to redo work on each instantiation, but I don't think the implementation/specification is more complex.
> preprocessor Macros are more complex than a text-based preprocessor. I understand how `cpp` works but the macro implementation (hygiene algorithm, etc.) is something I would need to read about quite a bit. > implicit numeric coercions We do have generic literals... > implicit pointer coercions We have these. & and &mut coerce to * and *mut, sometimes. There's sometimes automatic coercion to slices too. > overloadable coercions Auto-dereference/auto-reference can do pretty surprising things and I don't really understand the algorithm involved. Overloadable coercions are explicitly specified and the rules are pretty simple. > argument-dependent lookup This is quite similar to looking up a method based on the in-scope traits. > non-type template parameters This is a proposed feature for Rust, and it seems likely that we'll get associated constants. Integer type parameters are pretty much just sugar for that. > volatile Rust has this via intrinsics. > constexpr We do have syntax extensions, and CTFE is an often proposed feature. I don't know how likely it is that we'll get it. > runtime type information We have std::reflect, a type_id intrinsic and the venerable TyDesc. > allocators This is also proposed. > capture clauses We need something like this for unboxed closures unless we change the current semantics from an implicit non-first-class by-ref capture. > `->` syntax Auto-dereference is more complex. > multiple inheritance We do have multiple trait inheritance... and AFAIK supertraits are intended to work with trait objects. > pointer-to-member-functions We'll have this too AFAIK. How will first-class methods mix with single inheritance? > the subtle rules around "const", the `mutable` keyword Rust's support for mutability is better, but it's better in part because it's a more sophisticated system. `const` is dead simple when compared to inherited-mutability-but-sometimes-not-really (& &mut, non-Freeze types like Cell/RefCell, etc.). > the implicit `this` pointer and the `enable_shared_from_this` that you need, `const` member functions We have the complexity of `self` being special and allowing certain pointer sigil qualifications. > default arguments This is another proposed feature for Rust, and one I also really dislike. > exceptions You can't catch failure, but it's not really less complex at a language level. It makes the libraries much simpler since exception safety isn't a thing. > Without single inheritance, how do you solve the problems outlined in > this thread? I don't think Rust needs to support every kind of object system efficiently at a language level. I would only want it to pick a good one and support that (like trait objects) rather than trying to make the compiler directly support any foreign object system efficiently. In my opinion, supporting another object system would be good for Servo (or another browser engine) and bad for the language elsewhere... I can see why having an efficient DOM is important, but it doesn't make me not hate this feature. I don't think making COM/gobject incredibly efficient is a valid use case because both are terrible legacy technologies and both are already slow.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
