[swift-dev] SIL: "unowned" the calling convention and "unowned" the variable ownership convention

[Michael Gottesman]

> On Jan 4, 2016, at 4:35 PM, Michael Gottesman <mgottesman at apple.com> wrote:
> 
> The name doesn't really matter to me TBH (and as you can tell I am not an expert at such things like Jordan).
> 
> I just dislike having this 

Sorry for the cut off sentence. John/Jordan, do you have any naming thoughts?

Michael

> 
> Sent from my iPhone
> 
> On Jan 4, 2016, at 1:59 PM, John McCall <rjmccall at apple.com> wrote:
> 
>>> On Jan 4, 2016, at 11:07 AM, Jordan Rose via swift-dev <swift-dev at swift.org> wrote:
>>> Hi, Michael. The calling convention is equivalent to the 'unowned(unsafe)' variant of 'unowned', so I don't think it's entirely unrelated.
>>> 
>>> I don't like "Immediate" because I don't know what it means. Admittedly I don't work on SIL, but when is something passed "immediate" as opposed to "guaranteed"? Is "immediate" the case where it's valid now but mutating any external memory could make it invalid?
>> 
>> Yes.
>> 
>>> What makes that "immediate”?
>> 
>> The name is used in SILGen when you’re going to use a value “immediately”, i.e. before any code executes that could possibly invalidate the reference.  For example, the base expression of a load of a stored class property can be emitted as a +0 immediate r-value, because the caller is going to immediately project the property and load.  That allows us to e.g. not retain after loading from a var; it’s a minor but frequently-impactful SILGen optimization.
>> 
>> Anyway, I agree with Jordan that that name is not particularly appropriate for a parameter convention.
>> 
>> This really just affects documentation and code within the compiler: it’s not actually written in textual SIL because it’s the default convention.  Still, I’m fine with changing the name from “unowned”.  Something that suggests the temporary nature of validity, maybe — “fleeting”? :)  One consideration is that this is also the convention used for trivial values, although I suppose we could split that out (to “trivial”, which would of course be the default for trivial arguments) and maybe even always require an explicit convention on non-trivial arguments.
>> 
>> John.
>>