On 11/09/2013 06:43 AM, Kevin Ballard wrote:> On Nov 8, 2013, at 9:38 PM, Daniel
Micay <[email protected]> wrote:
On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard <[email protected]> wrote:
On Nov 8, 2013, at 2:21 PM, Patrick Walton <[email protected]> wrote:
I know that many people don't like the fact that, syntactically, vectors and
strings have a sigil in front of them, but please consider that there are many
design constraints here. What works for another language may not work for Rust,
because of these constraints.
Personally, I find it great that they have a sigil in front of them. It reminds
me that they're stored in the heap.
-Kevin
Since library containers, smart pointers and other types don't have them, I
don't think it's helpful in that regard.
Well no, you can't assume that the absence of a sigil means the absence of heap
storage. But for types that are possibly not stored on the heap, such as str (which
can be &'static str) and [T] (which can be a fixed-size stack-allocated
vector), the ~ is a useful distinction.
-Kevin
Can we, then, even consider the opposite: having a sigil for static data (mainly
literal strings stored in static mem, I'd say) or generally non-heap data (thus
including eg static arrays stored on stack)? The advantage is that this restores
coherence between all heap of heap data.
I'd use '$'! (what else can this sign be good for, anyway? ;-)
[But where should the sigil go? In front of the data literal, as in
let stst = $"Hello, world!";
let nums = $[1,2,3];
or in front of the type, or of the id itself?]
Also, is it at all possible, in the long term maybe, to consider letting the
compiler choose where to store, in cases where a possible pointer is
meaningless, that is it does not express a true reference (shared object, that
a.x is also b.y), instead is used for technical or efficiency reasons (that
memory is not elastic!, for avoiding copy, etc...)?
Denis
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
