Adding an intrinsics module #1573
Conversation
|
Converting to draft until tested and CI passes. |
| fn is_ref_type<T>(param: T) -> bool { | ||
| is_reference_type::<T>() | ||
| } | ||
|
|
||
| fn get_size_of<T>(param: T) -> u64 { | ||
| size_of::<T>() | ||
| } |
There was a problem hiding this comment.
I wonder if the actual library functions in the intrinsics module should do this? They seem a bit redundant otherwise. What is the motivation around creating the wrappers in the new module -- to hide the __ prefix?
I guess most intrinsics, like those which will wrap VM opcodes, are not really expected to be exposed to the average dev. They're more for low level library development, and we wouldn't need/want to wrap them. But these are designed for everyday use so sure, let's wrap. But I don't anticipate needing to put anything else in this module particularly..? 🤔
There was a problem hiding this comment.
to hide the
__prefix?
Yes, because the alternative is to make the specific names of the intrinsics part of the public API of the language. Which we could certainly do, but then it's one more set of keywords people have to account for.
But I don't anticipate needing to put anything else in this module particularly..?
Can't really think of anything either, but that's fine! Not every intrinsic needs to be available to the end user, as you said.
There was a problem hiding this comment.
I'm in favor of these wrappers to hide the __ prefix. It helps keep a nice uniform api surface for users.
All in the title.
close #1532