171–178 of 178 posts
Earlier quoted context omitted.
Rust could generate a bespoke internal proxy type.
Until then, we use `Either` ( https://stackoverflow.com/a/50204370/155423 )
Earlier quoted context omitted.
Until then, we use `Either` ( https://stackoverflow.com/a/50204370/155423 )
Tangentially, do you know why Rust never included an Either type? We have Result, which is great, but Either is useful for more things than errors (though that seems to be it's main use).
There’s a crate on crates.io for it if you want to use it for something.
Earlier quoted context omitted.
The argument for putting things in third-party "blessed" crates rather than the standard library is that it allows them not to have to follow the versioning guarantees of Rust itself. Given that the core team has stated that they don't plan to have a Rust 2.0, this means that there wouldn't _ever_ be any API-breaking changes for things added to the standard library; by having things like `regex` and `rand` be externa…
Do you know where I can find the comment about no plan for Rust 2.0? I tried googling it but I couldn't find it. Reason why I'd like to find it to have some guarantee that this is true. Cause it sounds like a strong commitment here.
Though we are calling them “editions” instead of “epochs” now.
Earlier quoted context omitted.
You're starting from the assumption that the Google developers took a clear-eyed decision on the merits, which I don't share.
What do you suggest guided their decision?
It's rational to take these factors into account, but they don't reflect on the merits of the language itself, and aren't necessarily transferable to other people choosing programming languages.
Earlier quoted context omitted.
what else would you say it is missing?
Not essential but keyword arguments / named parameters / default arguments . I love those in Python and OCaml/ReasonML.
http://play.rust-lang.org/?gist=4f74d3dcee0031e99cb99bb54da5...
Concerning keyword args as I remember them from Python you would probably have to hack something together with an Into>>
Concerning "named paramters" I think you would have to apply some of the same trickery in order to be able when calling the fn to leave out args or give them in a different order than specified in the fn header.
Or what I've sometimes seen written was (e.g. for configuration passing) structs created with Option that were then passed to one or more functions which in turn get the values (named params/default args if you will) from that "object", being able to pick and choose the appropriate values to get in a given function/method.
Is it possible to match the end of a slice with slice patterns? Something like: fn foo(s: &[char]) { match s { ['a', 'b'] => (), [.. 'b', 'c'] => (), _ => (), } }
Not today, but it's coming. This kind of thing does work on nightly.
some_collection.windows(2).filter(|[a,b]|a==b).map(|[a, _] |a).collect();
Maybe there has to be some special case handling for this pattern to be valid?
Earlier quoted context omitted.
Not today, but it's coming. This kind of thing does work on nightly.
I was mostly excited about slice patterns because of a pattern I wanted to be able to write: some_collection.windows(2).filter(|[a,b]|a==b).map(|[a, _] |a).collect(); Turns out the compiler rejects that with a "refutable pattern" error, because the args part of the filter/map closures do not handle the situation where the slice could be empty, which AFAIK can not occur when using windows/chunks/... Maybe there has to…
Earlier quoted context omitted.
I was mostly excited about slice patterns because of a pattern I wanted to be able to write: some_collection.windows(2).filter(|[a,b]|a==b).map(|[a, _] |a).collect(); Turns out the compiler rejects that with a "refutable pattern" error, because the args part of the filter/map closures do not handle the situation where the slice could be empty, which AFAIK can not occur when using windows/chunks/... Maybe there has to…
Hm, interesting. I think this isn't possible without integer generics.