Re: [rust-dev] Syntax of vectors, slices, etc

Some more thoughts on the matter: http://smallcultfollowing.com/babysteps/blog/2012/04/23/vectors-strings-and-slices/ Niko On 4/23/12 4:40 PM, Niko Matsakis wrote: One thing that is unclear to me is the utility of the str/N type. I can't think of a case where a *user* might want this type---i

Re: [rust-dev] Syntax of vectors, slices, etc

One thing that is unclear to me is the utility of the str/N type. I can't think of a case where a *user* might want this type---it seems to me to represent a string of exactly N bytes (not a buffer of at most N bytes). Graydon, did you have use cases in mind? Niko On 4/23/12 4:12 PM, Grayd

Re: [rust-dev] Syntax of vectors, slices, etc

On 12-04-23 03:21 PM, Rick Richardson wrote: > Should a str be subject to the same syntax? Because it will have > different semantics. I think the semantics are almost identical to vectors. Save the null issue. > A UTF-8 string has differently sized characters, so you can't treat > it as a vecto

Re: [rust-dev] Syntax of vectors, slices, etc

Should a str be subject to the same syntax? Because it will have different semantics. A UTF-8 string has differently sized characters, so you can't treat it as a vector, there are obvious and currently discussed interoperability issues regarding the null terminator. It should definitely get a sl

Re: [rust-dev] Syntax of vectors, slices, etc

On 12-04-23 12:58 PM, Rick Richardson wrote: > My line of thinking is this: > If you have an array of four Ints, the type of the array is 4 Ints. > It's incompatible with an array that is 5 ints without an adaptor. > Since [] indicates a vector, and a vector in Rust has both a length > and a type,

Re: [rust-dev] Syntax of vectors, slices, etc

I like your suggestion about having / always specify bound. However, syntactically decoupling the size of the type from the type seems odd. Also, I'm not sure how one would express multidimensional arrays. My line of thinking is this: If you have an array of four Ints, the type of the array is 4

Re: [rust-dev] String constans

On 12-04-22 05:19 PM, Alexander Stavonin wrote: > Do you have a plan to adding string constans? Or are you proposing some > other way for creating string constants? > > string_const.rs:3:18: 3:24 error: string constants are not supported > string_const.rs:3 const NAME: s

Re: [rust-dev] strings, slices and nulls

On 12-04-22 06:02 PM, Joe Groff wrote: > It would definitely be more forward-thinking to use slices as the > primary native mechanism for passing around strings and > memory-contiguous sequences in general. That is the current plan. I'm in the process of implementing it. https://github.com/mozil

Re: [rust-dev] 2 possible simplifications: reverse application, records as arguments

On Apr 23, 2012, at 8:34 AM, Patrick Walton wrote: > > * We'd still need formal parameters for C interoperability. At the ABI level, > a single-argument function applied to a 3-ary tuple is very different from a > function with 3 arguments. Could the rust calling convention behave similarly to

Re: [rust-dev] 2 possible simplifications: reverse application, records as arguments

On 04/21/2012 10:28 AM, gasche wrote: I've been wondering about a problem tightly related to named Re. function types: if you consider those parameter-passing structures as "first class" (which does necessarily mean that they are convenient to use, for example if they're not adressable they will

Re: [rust-dev] 2 possible simplifications: reverse application, records as arguments

> Note: OCaml has made the choice that (K _) is a pattern that matches > the constructor K no matter what its arity is (including none or > several parameters). While that doesn't help with the 'tps' example > above, it would still simplify a lot of places and does not require > named constructor a

Re: [rust-dev] 2 possible simplifications: reverse application, records as arguments

I've been wondering about a problem tightly related to named parameters: named enum constructor arguments. SML has had the ability to define algebraic datatypes as sum of (named) records, and I think that is something that is missing in current rust. The code antipattern that cries for it is patter