[swift-dev] Proposal: Opaque SIL values

[Andrew Trick]

> On Jan 26, 2017, at 8:33 AM, John McCall <rjmccall at apple.com> wrote:
> 
>> On Jan 24, 2017, at 2:10 PM, Andrew Trick via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> I’m sending out a proposal for fundamentally changing SIL. This work feeds into generic code optimization, resilience, semantic ARC, and SIL ownership. This was discussed at length back in October—some info went out on swift-dev—but I realized there hasn’t been a formal proposal. So here it is. I want to make sure enough people have seen this before pushing my PR that puts the infrastructure in place: https://github.com/apple/swift/pull/6922 <https://github.com/apple/swift/pull/6922>.
>> 
>> Rendered Proposal: https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7 <https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7>
>> 
>> Markdown:
>> <silval-proposal-1.md>
> 
> We've already talked about this at length, so I just want to say for the record that it looks great, and thanks for taking this on.
> 
> What's the purpose of SILFunctionConventions?  To provide a context with which to interpret the information in SILFunctionType?
> 
> John.

Yes, that’s the motivating factor. SILFunctionTypes are created as part of the ASTContext and I believe they should be immutable. A function's type should never change. SILFunctionConventions is a transient view of that type corresponding to the module’s current conventions.

I hope the separation of APIs also helps make the distinction between lowered types and SIL types. It’s hard for me to even talk about that distinction since they’ve always been the same thing.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170126/10c3aaa7/attachment.html>