> ...and possibly change `~`. To what?
-- Ziad On Tue, Nov 12, 2013 at 1:31 PM, Patrick Walton <[email protected]>wrote: > On 11/13/13 2:37 AM, Greg wrote: > >> 1. ~[Option<Bucket<K,V>>] >> >> 2. fn linear_map_with_capacity<K:Eq + Hash,V>(capacity: uint) -> >> LinearMap<K,V> >> >> 3. fn contains_key(&self, k: &K) >> >> My approach would be to try and get rid of templates through better >> type inference in the compiler. >> > > We need the ability to define custom generic containers, which are > essential for high-performance code. The Go/JS-like approach of building a > few blessed containers into the language doesn't work when you need > fine-grained control over data representations, which we need to build a > competitive browser engine among other considerations. > > > I'd introduce the common brace >> literal syntax for maps that can be found in JS and elsewhere, and >> perhaps additional literal syntax (ala ObjC + Clojure). >> > > We use the brace literal syntax for objects already, so we need something > different. I do think that having a map literal syntax would be nice, but > that can probably be done via the macro system for now. > > > I'd also look at the symbols '~', '@', and '&', and see what could be >> done to remove or simplify those. >> > > The current thinking is to remove `@` and possibly change `~`. `&` will > likely not change because of familiarity from C++. > > > I'd look to see whether ARC could be used instead of garbage >> collection, and whether that would have an impact on syntax or not. >> > > We do support reference counting. The fact that we offer GC is a choice > that gives control to the programmer. > > A broader point, though, is that syntax seems to me to be a very > unimportant concern when making decisions that impact performance and > control. Users of high-performance software, who vastly outnumber the > developers and who never see the source code, aren't going to accept > tradeoffs made to source-level aesthetics that simultaneously have the > effect of making their software slow. > > > There's also the question of whether symbols (ala >> Lisp/Scheme/Clojure) could be useful in simplifying the language and >> making it more versatile. >> > > Can you elaborate? > > Patrick > > _______________________________________________ > 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
