Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Some kind of type-of operator #1948

Closed
marijnh opened this issue Mar 9, 2012 · 6 comments
Closed

RFC: Some kind of type-of operator #1948

marijnh opened this issue Mar 9, 2012 · 6 comments
Labels
A-codegen Area: Code generation
Milestone

Comments

@marijnh
Copy link
Contributor

marijnh commented Mar 9, 2012

Monomorphization (assuming I'll be able to land it anytime soon) has removed the need to pass type descriptors to generics. The only place were we still are passing type descriptors is to rust-intrinsic functions. I'd like to switch those over to explicit type-descriptor passing (most of them don't even use their type descriptors), but sys::get_type_desc is currently implemented as an intrinsic that returns the type descriptor it is passed. Thus, we'd have to provide some other way to get at tydescs.

Ideally, this would be some hack in core and not add anything to the language. But when our compiler stops passing tydescs to things, it becomes very hard to get hold of them. You can box something and then unsafely fetch the tydesc from the box, but that's definitely not how we want to create tydescs. So the compiler will have to cooperate in some way.

I'm having trouble coming up with a non-invasive way to do this. We could hard-code core::sys::get_type_desc to always magically return the type desc of its type parameter. We could do something with attributes.

Do others have ideas? Do you think I'm even going in the right direction here? The code to handle passing tydescs to intrinsics is very awkward, now that normal functions no longer take tydescs. It seems like an undesirable wart.

@nikomatsakis
Copy link
Contributor

Yes, I remember @pcwalton @brson and I talked about this problem a while back and I forget what we decided would be best. It seems like you've enumerated the options, though. Even if we get rid of tydesc/intrinsics, I think we will need sizeof() and alignof() operators, if nothing else, and you kind of have the same problem there---but perhaps they could be added as keywords to the language?

@nikomatsakis
Copy link
Contributor

FWIW, I'm ok with either hard-coding core::sys::get_type_desc() into trans or adding some magic attribute. You have to make the link somehow.

@brson
Copy link
Contributor

brson commented Mar 9, 2012

I don't prefer hard-coding the name of something in core. What about leaving it a "rust-intrinsic" native ABI function but just having the compiler recognize it by name and generate it on demand? The intrinsic functions are all special and, from an end-user perspective, appear to be generated by rustc anyway.

@graydon
Copy link
Contributor

graydon commented Mar 11, 2012

Agreed. This is exactly the sort of thing "intrinsic" is for: stuff that "looks like a function" but only a compiler can generate.

@brson
Copy link
Contributor

brson commented Apr 2, 2012

@marijnh Is this resolved?

@marijnh
Copy link
Contributor Author

marijnh commented Apr 3, 2012

Yes, there's the get_tydesc intrinsic for this now. Closing.

@marijnh marijnh closed this as completed Apr 3, 2012
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation
Projects
None yet
Development

No branches or pull requests

4 participants