@@ -41,11 +41,11 @@ directly as part of the public API.
41
41
have the "Rust" ABI then the problem is solved.
42
42
43
43
Under this scheme intrinsics will be declared as ` extern "Rust" ` functions
44
- and identified as intrinsics with the ` #[intrinsic ] ` attribute:
44
+ and identified as intrinsics with the ` #[lang = "..." ] ` attribute:
45
45
46
46
```
47
47
extern "Rust" {
48
- #[intrinsic ]
48
+ #[lang = "transmute" ]
49
49
fn transmute<T, U>(T) -> U;
50
50
}
51
51
```
@@ -54,13 +54,24 @@ The compiler will type check and translate intrinsics the same as today.
54
54
Additionally, when trans sees a "Rust" extern tagged as an intrinsic
55
55
it will not emit a function declaration to LLVM bitcode.
56
56
57
+ Because intrinsics will be lang items, they can no longer be redeclared
58
+ arbitrary number of times. This will require a small amount of existing
59
+ library code to be refactored, and all intrinsics to be exposed through public
60
+ abstractions.
61
+
62
+ Currently, "Rust" foreign functions may not be generic; this change
63
+ will require a special case that allows intrinsics to be generic.
64
+
57
65
# Alternatives
58
66
59
- 1 . Instead of the new ` #[intrinsic] ` attribute we could make intrinsics
60
- lang items. This would require either forcing them to be 'singletons'
61
- or create a new type of lang item that can be multiply-declared.
67
+ 1 . Instead of making intrinsics lang items we could create a slightly
68
+ different mechanism, like an ` #[intrinsic] ` attribute, that would
69
+ continue letting intrinsics to be redeclared.
70
+
71
+ 2 . While using lang items to identify intrinsics, intrinsic lang items
72
+ * could* be allowed to be redeclared.
62
73
63
- 2 . We could also make "rust-intrinsic" coerce or otherwise be the same
74
+ 3 . We could also make "rust-intrinsic" coerce or otherwise be the same
64
75
as "Rust" externs and normal Rust functions.
65
76
66
77
# Unresolved questions
0 commit comments