> On Oct 3, 2017, at 9:14 PM, Jonas B via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
> Now I understand that this use-case is deferred for a later separate
> discussion, but my point here is that the name and the semantics of this
> attribute should be somewhat “forward-compatilble” with this use-case. “
> inlinable” does not sound appropriate, because we don’t want to “inline” (in
> the C/C++ meaning) declarations into each usage site.
> Instead we want to compile the annotated parts of -all linked modules- as one
> unit. Basically, for those parts, the module name would just function like a
> C++ namespace - an input to the symbol name mangling, and then the whole
> thing could be whole-module-optimized together.
Yeah, @inlinable does not actually force any kind of inlining to be performed —
it declared that the SIL for the function body should be serialized as part of
the module.
>
> This touches upon another comment someone made previously in this discussion
> - that access level and compiler visibility should be separate concepts.
> Because not just public methods, also private methods should be subject to
> this.
The undocumented @_versioned attribute is currently used to make something
visible to the compiler without making it visible in the language. It sounds
like there’s some interest in documenting this attribute too — can someone
suggest a better name than @_versioned? If we converge on a design here I can
incorporate that into the proposal, relaxing the restriction that @inlinable
functions can only reference other public functions.
Slava
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
