Triaging old radars, I came across rdar://27268632 <rdar://27268632> from Dmitri. The gist of it is that he was proposing grouping up all the random global functions that are implicitly called by the compiler under a “namespace” by making them static methods of an enum called _Intrinsic. (This name is kind’ve confusing, because it seems to be the opposite of the traditional notion of an intrinsic. _RuntimeHook?)
Since this affects how the compiler interfaces with the standard library, I figured I should check with everyone what they think about doing this. This is an ABI stability issue, because future compilers will emit these symbols.
I don’t really have a strong opinion on the matter. Avoiding global pollution and clarifying interfaces seems nice?
I agree. It'd be general goodness to enumerate the set of things the compiler expects the standard library to provide, and to see if there's any cleaning up or simplification of these interfaces we can do before ABI lockdown.
-Joe
···
On Dec 15, 2016, at 3:46 PM, Alexis via swift-dev <swift-dev@swift.org> wrote:
Triaging old radars, I came across rdar://27268632 from Dmitri. The gist of it is that he was proposing grouping up all the random global functions that are implicitly called by the compiler under a “namespace” by making them static methods of an enum called _Intrinsic. (This name is kind’ve confusing, because it seems to be the opposite of the traditional notion of an intrinsic. _RuntimeHook?)
Since this affects how the compiler interfaces with the standard library, I figured I should check with everyone what they think about doing this. This is an ABI stability issue, because future compilers will emit these symbols.
I don’t really have a strong opinion on the matter. Avoiding global pollution and clarifying interfaces seems nice?
on Thu Dec 15 2016, Alexis <swift-dev-AT-swift.org> wrote:
Triaging old radars, I came across rdar://27268632 <rdar://27268632>
from Dmitri. The gist of it is that he was proposing grouping up all
the random global functions that are implicitly called by the compiler
under a “namespace” by making them static methods of an enum called
_Intrinsic. (This name is kind’ve confusing, because it seems to be
the opposite of the traditional notion of an intrinsic. _RuntimeHook?)
Since this affects how the compiler interfaces with the standard
library, I figured I should check with everyone what they think about
doing this. This is an ABI stability issue, because future compilers
will emit these symbols.
I don’t really have a strong opinion on the matter. Avoiding global
pollution and clarifying interfaces seems nice?
One thing to be careful with here is that sometimes SIL test cases say that are the stdlib but only implement the functionality that they will use (taking advantage of how I believe currently these are checked lazily). If I am correct (which my memory may not be), we will need a flag to be less strict perhaps or something like that?
Keep in mind, I would only suggest implementing this idea if the patch that moves this change making the intrinsics explicit triggers this issue.
Michael
···
On Dec 16, 2016, at 10:46 AM, Joe Groff via swift-dev <swift-dev@swift.org> wrote:
On Dec 15, 2016, at 3:46 PM, Alexis via swift-dev <swift-dev@swift.org> wrote:
Triaging old radars, I came across rdar://27268632 from Dmitri. The gist of it is that he was proposing grouping up all the random global functions that are implicitly called by the compiler under a “namespace” by making them static methods of an enum called _Intrinsic. (This name is kind’ve confusing, because it seems to be the opposite of the traditional notion of an intrinsic. _RuntimeHook?)
Since this affects how the compiler interfaces with the standard library, I figured I should check with everyone what they think about doing this. This is an ABI stability issue, because future compilers will emit these symbols.
I don’t really have a strong opinion on the matter. Avoiding global pollution and clarifying interfaces seems nice?
I agree. It'd be general goodness to enumerate the set of things the compiler expects the standard library to provide, and to see if there's any cleaning up or simplification of these interfaces we can do before ABI lockdown.