One form of overloading that we currently have at the SIL level are the notions of the "unowned" calling convention and "unowned" the variable ownership convention.
For those who are unfamiliar with the unowned calling convention consider the following:
In this case the first parameter is passed in @owned (i.e. +1) and the second parameter is passed in as "unowned". Unowned is a form of +0 parameter passing that essentially means that the callee needs to take ownership of the value (ideally) before performing any side-effect having operations.
Overloading the term "unowned" in this way is confusing for new people at the SIL level. I would like to propose that we rename the unowned calling convention to something else (since unowned the variable ownership convention corresponds to a swift level concept that will be more difficult to change). Additionally no matter what we do, we should annotate "unowned" parameters and return values with an appropriate @"..." sigil to make it absolutely clear visually what the convention is.
In terms of names, I am partial to the name "immediate". My reasoning for using the term immediate is related to SGFContext in SILGen. In SILGen, there are three types of desired transfers defined by the DesiredTransfer enum.
PlusOne refers to @owned, GuaranteedPlusZero refers to @guaranteed, and if my memory is correct, ImmediatePlusZero refers to unowned. It seems natural to me to choose immediate for the name of the convention to match the terminology in SGFContext.
Prior to this e-mail, it wasn't clear to me that there were two
different "unowned" concepts.
+1 in favor of the rename.
--Emanuel
···
On Tue, Dec 29, 2015 at 3:18 PM, Michael Gottesman via swift-dev <swift-dev@swift.org> wrote:
One form of overloading that we currently have at the SIL level are the notions of the "unowned" calling convention and "unowned" the variable ownership convention.
For those who are unfamiliar with the unowned calling convention consider the following:
In this case the first parameter is passed in @owned (i.e. +1) and the second parameter is passed in as "unowned". Unowned is a form of +0 parameter passing that essentially means that the callee needs to take ownership of the value (ideally) before performing any side-effect having operations.
Overloading the term "unowned" in this way is confusing for new people at the SIL level. I would like to propose that we rename the unowned calling convention to something else (since unowned the variable ownership convention corresponds to a swift level concept that will be more difficult to change). Additionally no matter what we do, we should annotate "unowned" parameters and return values with an appropriate @"..." sigil to make it absolutely clear visually what the convention is.
In terms of names, I am partial to the name "immediate". My reasoning for using the term immediate is related to SGFContext in SILGen. In SILGen, there are three types of desired transfers defined by the DesiredTransfer enum.
PlusOne refers to @owned, GuaranteedPlusZero refers to @guaranteed, and if my memory is correct, ImmediatePlusZero refers to unowned. It seems natural to me to choose immediate for the name of the convention to match the terminology in SGFContext.
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? What makes that "immediate"?
Jordan
···
On Dec 29, 2015, at 15:18, Michael Gottesman via swift-dev <swift-dev@swift.org> wrote:
One form of overloading that we currently have at the SIL level are the notions of the "unowned" calling convention and "unowned" the variable ownership convention.
For those who are unfamiliar with the unowned calling convention consider the following:
In this case the first parameter is passed in @owned (i.e. +1) and the second parameter is passed in as "unowned". Unowned is a form of +0 parameter passing that essentially means that the callee needs to take ownership of the value (ideally) before performing any side-effect having operations.
Overloading the term "unowned" in this way is confusing for new people at the SIL level. I would like to propose that we rename the unowned calling convention to something else (since unowned the variable ownership convention corresponds to a swift level concept that will be more difficult to change). Additionally no matter what we do, we should annotate "unowned" parameters and return values with an appropriate @"..." sigil to make it absolutely clear visually what the convention is.
In terms of names, I am partial to the name "immediate". My reasoning for using the term immediate is related to SGFContext in SILGen. In SILGen, there are three types of desired transfers defined by the DesiredTransfer enum.
PlusOne refers to @owned, GuaranteedPlusZero refers to @guaranteed, and if my memory is correct, ImmediatePlusZero refers to unowned. It seems natural to me to choose immediate for the name of the convention to match the terminology in SGFContext.
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.
···
On Jan 4, 2016, at 11:07 AM, Jordan Rose via swift-dev <swift-dev@swift.org> 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
···
On Jan 4, 2016, at 4:35 PM, Michael Gottesman <mgottesman@apple.com> wrote:
Sent from my iPhone
On Jan 4, 2016, at 1:59 PM, John McCall <rjmccall@apple.com> wrote:
On Jan 4, 2016, at 11:07 AM, Jordan Rose via swift-dev <swift-dev@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.