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
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to