On Sat, Apr 28, 2012 at 8:12 AM, Marijn Haverbeke <mari...@gmail.com> wrote:
> I must say I prefer Graydon's syntax. `[]T` sets off all kinds of > alarms in my head. > > I have no strong opinion on dynamically-sized types. Not having them > is definitely a win in terms of compiler complexity, but yes, some of > the things that they make possible are nice to have. > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > Hello Niko, First I really appreciate you thinking hard about it and if you don't want to bother the list I would certainly not mind talking it out with you in private; I feel it's very important for these things to be thought through extensively and I really like that decisions in Rust are always considered carefully and objectively. That being said, I have two remarks: I would like to ask a question on the vectors syntax: why the focus on [] ? I understand it in the literal form, however a string type is denoted as `str` so why not denote a vector of Ts as `vec<T>` ? Yes, it's slightly more verbose, but this is how all the other generic types will be expressed anyway. Similarly, since a substring is expressed as `substr`, one could simply express a slice as `slice<T>` or `svec<T>` or even `array_ref<T>`. I don't think being overly clever with the syntax type will really help the users. Imagine grepping for all uses of the slice type in a crate ? It's so much simpler with an alphabetic name. (Also, `[:]/&r T` feel *really* weird, look at the mess C is with its pointer to function syntax that let's you specify the name in the *middle* of the type...) As for types of unknown sizes, I would like to point out that prevent users from having plain `str` attributes in their records is kinda weird. The pointer syntax is not only more verbose, it also means that suddenly getting a local *copy* of the string gets more difficult. Sure it's equivalent (semantically) to a unique pointer `~str`, but it does not make copying easier, while it's one of the primary operations in impure languages (because the original may easily get modified at a later point in time). I think that `rust_vec<T>` having an unknown size rather than being (in effect) a pointer to a heap allocated structure is nice from an implementation point of view, but it should not get in the way of using it. I would therefore venture that either it has an unknown size and the compiler just extend this unknown size property to all types so they can have `vec<T>` and `str` attributes naturally, or it's better for it *not* to have an unknown size. I would also like to point out that if it's an implementation detail, the actual representation might vary from known size to unknown size without impact for the user, so starting without for the moment because it's easier and refining it later is an option. Another option is to have a fixed size with an alternative representation using something similar to SSO (Short String Optimization); that is small vectors/strings allocate their storage in place while larger ones push their storage to the heap to avoid trashing the stack. Hope this does not look harsh, I sometimes have difficulties expressing my opinions without being seen as patronizing: I can assure you I probably know less than you do :) -- Matthieu
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
