[rust-dev] In favor of types of unknown size

Matthieu Monrocq matthieu.monrocq at gmail.com
Sat Apr 28 03:17:44 PDT 2012


On Sat, Apr 28, 2012 at 8:12 AM, Marijn Haverbeke <marijnh at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20120428/07fd4f8a/attachment.html>


More information about the Rust-dev mailing list