> On Jan 26, 2017, at 8:33 AM, John McCall <rjmcc...@apple.com> wrote:
>
>> On Jan 24, 2017, at 2:10 PM, Andrew Trick via swift-dev <swift-dev@swift.org
>> <mailto:swift-dev@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
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
