> On Jan 4, 2016, at 4:35 PM, Michael Gottesman <[email protected]> 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 <[email protected]> wrote: > >>> On Jan 4, 2016, at 11:07 AM, Jordan Rose via swift-dev >>> <[email protected]> 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. >> _______________________________________________ swift-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-dev
