tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
[personal profile] tim
Today, I finished fixing issue 2284 -- I'm just doing the final test run, then I'll submit a pull request (not push directly this time!)

This is sort of a weird bug. Rust had a notion of "kinds" that was distinct from our notion of traits, because kinds existed before traits did. If you know what kinds mean in other languages, it's more or less the same in Rust. If not: a kind is just the type of a type. Just like values have types so that the compiler can check that you're using them in ways that make sense, so do types have kinds, so that you can be prevented from using types in a nonsensical way.

Rust's kinds, though, are unusual: we had four constant kinds, const, owned, send, and copy, which can also be combined. So a given type could have none, some, or all of these kinds. The copy kind, for example, describes types whose values are allowed to be copied.

Once we introduced traits, it made sense to look at kinds as special traits that were wired into the compiler. So that's what I did to fix #2284. This had the nice effect of making the AST representation of type param bounds (a bound is the thing after the colon when you write <T: Copy> as a parameter list) much simpler: there were no longer any special cases for the built-in kinds. Now, resolve resolves references to things like Copy to placeholder traits that get defined in the core library, and the typechecker special-cases to turn these into specially represented bounds in the ty::param_bound data structure when it sees references to the placeholders.

For this bug, the net effect is that now, you can override Copy and other built-in traits/kinds with your own traits if you really want to. The one weird thing that happens now is that if you use the #[no_core] attribute to say you don't want to import the core library, you won't be able to use the Copy trait in your type parameter declarations -- but that's probably not so bad.

(no subject)

Date: 2012-10-17 10:45 pm (UTC)
luinied: How civilized! (academic)
From: [personal profile] luinied
The copy kind, for example, describes types whose values are allowed to be copied.

That sounds pleasantly familiar!

I have thought some about how substructural-stuff-as-kinds could be adapted from actually being about kinds to living in a more traditional subtyping hierarchy, but what got me is that you could never be sure that a type forbids copying. Because no matter where the presumably uncopyable type T is in your type hierarchy, someone can always define S as a subtype of T that also implements Copy, so nothing that uses a T can do anything under the hood that's only safe if that T absolutely can't be copied.

But maybe that's not an issue for what you're doing. Or maybe Rust doesn't have the sort of subtyping that I'm imagining? I'll admit to leaving this comment without reading the documentation.
Edited (Why are fixed-width fonts always shorter, again?) Date: 2012-10-17 10:49 pm (UTC)

(no subject)

Date: 2012-10-19 08:40 pm (UTC)
luinied: And someday, together, we'll shine. (Default)
From: [personal profile] luinied
I think the concerns I have might also be a non-issue if, when you're extending something to implement Copy you have to explicitly say (even if very briefly) how you're going to do the copying, and if, for the cases that you don't want ever to be copyable/aliased, it's impossible define a copy method (or whatever) that copies/aliases them by any indirect trickery. Which I'll bet is an easier thing to make sure of when you're creating your own language than it would be if you were trying to graft this onto, say, Scala, which is what I was thinking about when these problems first came to mind.


tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
Tim Chevalier

October 2017

8910 11121314
15 161718192021

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags

No cut tags