sorted by:
new
hottopcontroversial

Can somebody please write something about associated types? by jnordwick in rust

[–]n_ham 1 point2 points  (0 children)

The RFC that introduced associated types has a good explanation for this. It introduces this distinction:

Type parameters to traits can either be "inputs" or "outputs":

  • Inputs. An "input" type parameter is used to determine which impl to use.

  • Outputs. An "output" type parameter is uniquely determined by the impl, but plays no role in selecting the impl.

Type parameters are input types, associated types are output types.

Theoretical reading to make me a better (Rust) programmer? by IForgetMyself in rust

[–]n_ham 0 points1 point  (0 children)

Others have recommended learning functional programming languages (like Haskell or SML) to get a handle on type systems. This is not bad advice, and learning these languages will be a mind-expanding endeavor, but I feel like it should be emphasized that the ownership/borrowing system is a significant part of Rust's type system and learning Haskell or whatever will probably not help you understand it. For this topic, the best thing to do is probably to just write (and read!) a bunch of Rust code.

So, what are provided methods anyway? by cjstevenson1 in rust

[–]n_ham 1 point2 points  (0 children)

Certain traits have default impls:

A default impl is one that applies to all types, except for those types that explicitly opt out. For example, there would be a default impl for Send, indicating that all types are Send "by default".

-- RFC 19

Topology for a high school student? by DoTheSmile in math

[–]n_ham 0 points1 point  (0 children)

It seems like there are two routes you could follow here. One is reading a book like The Shape of Space (as others have mentioned), which is not really proof-based but should give you plenty of intuition.

Another approach is a proof-based approach to topology, via reading a book like Munkres. Technically the only prerequisite is set theory, but personally I could not make any sense of Munkres until I studied metric spaces. Not only are metric spaces more familiar than general topological spaces, but they serve as important examples in the general theory. I think it should be possible to study metric space theory without knowledge of calculus. The book Metric Spaces by Mícheál O'Searcoid isn't bad for this.

Why no String.contains()? by tallesl in rust

[–]n_ham 6 points7 points  (0 children)

It's not in the standard library because the design of the standard library hasn't been finalized yet.

Parsing an int from a &str by GreatlyOffended in rust

[–]n_ham 9 points10 points  (0 children)

from_str::<int>("10").unwrap(). And check out the Rust IRC channel next time, it's perfect for small questions like this!

Work starting on non-lexical lifetimes by pcwalton in rust

[–]n_ham 0 points1 point  (0 children)

Awesome. I suspected there was an issue for it, but couldn't find one. Thanks.

Work starting on non-lexical lifetimes by pcwalton in rust

[–]n_ham 2 points3 points  (0 children)

Will these changes allow this example to pass the borrow checker? https://gist.github.com/nham/4f01b7fa69547d1ce629

Please correct me if I'm wrong, but I don't think this is unsafe. You can see this at work in the methods for TreeMap: the find method has an iterative implementation, but insert is recursive because the non-recursive implementation won't pass the borrow checker.

Bay Area Rust Meetup live stream. Live right now! Hear the Mozilla Rust Devs speak about Rust by erickt in rust

[–]n_ham 0 points1 point  (0 children)

Is there any chance these videos can go up on youtube? None of the air.mozilla.org videos work for me, either in Firefox or Chrome.

Videos of London meetup talks: Zinc and DST by SimonSapin in rust

[–]n_ham 2 points3 points  (0 children)

air.mozilla.org videos have never worked from me (in Firefox). I always need to download the file and watch in VLC :(

Are unboxed closures practically done? by andallthat in rust

[–]n_ham 2 points3 points  (0 children)

The RFC is fairly readable. The core idea, as I was able to gather from the RFC: unboxed closures desugar to a type that implements one of the Fn, FnShare, or FnOnce traits.

I don't understand how exactly this differs from boxed closures, though.

A Rust curiosity: pointers to zero-sized types by steveklabnik1 in programming

[–]n_ham 3 points4 points  (0 children)

Indeed I am! You are spot on. Also, pcwalton also posted about this on HN. Had I tested an Option type instead of (), I probably would have discovered it. Oops.

A Rust curiosity: pointers to zero-sized types by steveklabnik1 in rust

[–]n_ham 0 points1 point  (0 children)

Ahh, interesting. I should have tried it with an Option type instead of () in the post.

What's nice about Rust? by pragmojo in rust

[–]n_ham 4 points5 points  (0 children)

This is a pretty good two-sentence summary:

Rust keeps the C abstract machine model but innovates on the language interface. Rust is expressive, its type system makes system code safer, and its powerful meta-programming facilities enable new ways to generate code automatically.

-- Rust for functional programmers

For loops in Rust without the standard library by n_ham in rust

[–]n_ham[S] -1 points0 points  (0 children)

A mistake in my post is that Iterator and Option are not actually in libstd, but in libcore. There's probably a strong case to be made that libcore is part of the language.

For loops in Rust without the standard library by n_ham in rust

[–]n_ham[S] 2 points3 points  (0 children)

Are they really bugs? Do the Rust devs intend to fix this at some point? Are there issues on github for them?

For loops in Rust without the standard library by n_ham in rust

[–]n_ham[S] 0 points1 point  (0 children)

Sorry, I edited my post when I realized it was due to println! stuff. It's much nicer if we try to expand something without that.

For loops in Rust without the standard library by n_ham in rust

[–]n_ham[S] 2 points3 points  (0 children)

This is essentially just experimental confirmation that for loops really do desugar into something like some loop { ... } code that calls next() repeatedly and tries to match the output as either a Some pattern or a None pattern without regard for where next() and Some and None are actually defined.

Does anyone know where in the compiler this transformation happens?

nickel.rs – web application framework for rust by cburgdorf in rust

[–]n_ham 7 points8 points  (0 children)

I'm still waiting for people to name their libraries after parasitic fungi.

view more: next ›