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.
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,
On 04/28/2012 03:17 AM, Matthieu Monrocq wrote:
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
On Apr 27, 2012, at 11:03 PM, Marijn Haverbeke mari...@gmail.com wrote:
What Joe meant is that you could simply write multiple impls on the
same type with different names for the various modes of iteration.
impl of iter for maptype { ... }
impl iter_keys of iter for maptype { ... }
I'd honestly be ok with going back to vecT or vecmut T for the vector
type and using [T] for the slice, to discourage this hazard.
I think this could be a win for clarity. There are enough potential use
cases here that overloading [] doesn't seem to give all that much benefit.
On Sat, Apr 28,
The main thing I was trying to argue for is not a specific syntax but
rather the idea that a leading @, ~, or sigil indicates the kind of
pointer, and what comes after indicates the data that is being pointed
at. The orthogonality appeals to me; it seems to make the language fit
together
On Fri, Apr 27, 2012 at 3:15 PM, Niko Matsakis n...@alum.mit.edu wrote:
The types `[]T` and `str` would represent vectors and strings,
respectively. These types have the C representation `rust_vecT` and
`rust_vecchar`. They are of *dynamic size*, meaning that their size
depends on their
