There's also a possibility that we add 'out' parameters in the future, and
if 'inout' would be spelled '&', then we would need to find another sigil
for 'out'.
We have multiple returns. Why would we ever add out parameters?
I don't want to turn this thread into a discussion about out
parameters, but one reason would be to replace
AutoreleasingUnsafeMutablePointer.
IMO we should eventually import out params from C as multiple returns.
Another one is to add labels to
the output parameters:
let (day, month, year) = parseDate()
let (year, day, month) = parseDate() // bug?
Labeled tuples seem like they could help with that, with compiler QoI to catch cases like this where you obviously permuted the return names.
-Joe
···
On Dec 18, 2015, at 6:52 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Fri, Dec 18, 2015 at 6:21 PM, Joe Groff <jgroff@apple.com> wrote:
On Dec 18, 2015, at 6:08 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Sat, Dec 19, 2015, at 07:06 PM, Jordan Rose via swift-evolution wrote:
-1 to using '&' in the declaration; it's a sigil that doesn't mean
anything as is. (I was originally on the side of using 'inout' at the
call site as well, i.e. "swap(inout x, inout y)", but it was
considered too verbose.)
I don't like it as an attribute because attributes generally don't
affect the *syntax* of how something is used; they're mostly just
implementation detail. Obviously they can have important semantics
(like "@objc(…)" controlling the selector, or '@convention(c)' for C-
compatible function pointers), but for the most part they don't change
what the declaration is, whereas 'inout' *definitely* does.
Given that we already use this syntax for function types when the
parameter is unnamed, '(inout Int, inout named: Int) -> Void', I think
Erica's first suggestion is my favorite so far.
Jordan
On Dec 19, 2015, at 16:10 , Erica Sadun via swift-evolution <swift- >> evolution@swift.org> wrote:
What would the ramifications of the following be? Each addresses the
"confusable with labeling" issue but preserve the inout keyword.
Is there an underlying reason that parameter modification should live
on the name side rather than the type side of the colon? They aren't
really modifying the name
-- Erica, inexperienced with Rust
On Dec 18, 2015, at 7:07 PM, Chris Lattner via swift-evolution <swift- >>> evolution@swift.org> wrote:
On Dec 18, 2015, at 5:23 PM, Joe Groff via swift-evolution <swift- >>>> evolution@swift.org> wrote:
For Swift 3, we're planning to phase out 'var' parameters in
functions, and we're also making it so that language keywords are
valid argument labels. With both of these changes pending, I have a
hard time not reading:
func foo(inout x: Int)
as an argument labeled `inout` instead of an unlabeled argument
bound to `x`. Once `var` is phased out, `inout` would also be the
only remaining case where quoting is necessary to use a name as an
argument label. The `inout` keyword has always struck me as weird,
since it violates definition-follows-use—maybe we should replace it
with the `&` sigil, mirroring its usage in call sites.
-1
“inout” is intended to communicate (or at least hint at) the copy-in
/ copy-out behavior of the argument. It is also there to enable
other parameter modifiers, which can enable other more advanced
parameters models in the future (e.g. rust-style borrowing).
Is there an underlying reason that parameter modification should live on the name side rather than the type side of the colon? They aren't really modifying the name
-- Erica, inexperienced with Rust
Putting `inout` after the colon feels good to me. Like Jordan said, it meshes better with the type syntax, (inout Int) -> (), too.
+1. I like it.
···
On Dec 21, 2015, at 12:25 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
On Dec 19, 2015, at 4:10 PM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:
I have always thought "&" was problematic for that reason. The question is whether it's problematic enough to change.
-Dave
···
On Dec 19, 2015, at 7:12 PM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org> wrote:
On Sat, Dec 19, 2015 at 7:06 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
-1 to using '&' in the declaration; it's a sigil that doesn't mean anything as is. (I was originally on the side of using 'inout' at the call site as well, i.e. "swap(inout x, inout y)", but it was considered too verbose.)
I'd actually suggest that we reconsider this. '&' at the callsite has deep associations with C semantics, and I have too frequently seen buggy code using '&x' combined with one of the C interop implicit conversions to "get a pointer" that the code stores in a variable somewhere. It is also hard to explain to people that '&x' does not do what they want in that case, "& means address-of, and it returns a pointer here, what do you mean I can't use it?"
Using `inout` at the call site seems reasonable to me. I'd bet the vast majority of `inout` parameters are really the implicit `self` of mutating methods, which already get a pass, so aside from `swap` I wonder how often `&` is in practice.
-Joe
···
On Dec 19, 2015, at 7:12 PM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org> wrote:
On Sat, Dec 19, 2015 at 7:06 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
-1 to using '&' in the declaration; it's a sigil that doesn't mean anything as is. (I was originally on the side of using 'inout' at the call site as well, i.e. "swap(inout x, inout y)", but it was considered too verbose.)
I'd actually suggest that we reconsider this. '&' at the callsite has deep associations with C semantics, and I have too frequently seen buggy code using '&x' combined with one of the C interop implicit conversions to "get a pointer" that the code stores in a variable somewhere. It is also hard to explain to people that '&x' does not do what they want in that case, "& means address-of, and it returns a pointer here, what do you mean I can't use it?"
On Mon, Dec 21, 2015 at 10:34 AM, Joe Groff <jgroff@apple.com> wrote:
On Dec 18, 2015, at 6:52 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Fri, Dec 18, 2015 at 6:21 PM, Joe Groff <jgroff@apple.com> wrote:
On Dec 18, 2015, at 6:08 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
There's also a possibility that we add 'out' parameters in the future, and
if 'inout' would be spelled '&', then we would need to find another sigil
for 'out'.
We have multiple returns. Why would we ever add out parameters?
I don't want to turn this thread into a discussion about out
parameters, but one reason would be to replace
AutoreleasingUnsafeMutablePointer.
IMO we should eventually import out params from C as multiple returns.
Another one is to add labels to
the output parameters:
let (day, month, year) = parseDate()
let (year, day, month) = parseDate() // bug?
Labeled tuples seem like they could help with that, with compiler QoI to catch cases like this where you obviously permuted the return names.
On Dec 21, 2015, at 10:44 AM, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:
I agree 100% with everything Jordan said.
-Kevin Ballard
On Sat, Dec 19, 2015, at 07:06 PM, Jordan Rose via swift-evolution wrote:
-1 to using '&' in the declaration; it's a sigil that doesn't mean anything as is. (I was originally on the side of using 'inout' at the call site as well, i.e. "swap(inout x, inout y)", but it was considered too verbose.)
I don't like it as an attribute because attributes generally don't affect the syntax of how something is used; they're mostly just implementation detail. Obviously they can have important semantics (like "@objc(…)" controlling the selector, or '@convention(c)' for C-compatible function pointers), but for the most part they don't change what the declaration is, whereas 'inout' definitely does.
Given that we already use this syntax for function types when the parameter is unnamed, '(inout Int, inout named: Int) -> Void', I think Erica's first suggestion is my favorite so far.
Jordan
On Dec 19, 2015, at 16:10 , Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
What would the ramifications of the following be? Each addresses the "confusable with labeling" issue but preserve the inout keyword.
Is there an underlying reason that parameter modification should live on the name side rather than the type side of the colon? They aren't really modifying the name
-- Erica, inexperienced with Rust
On Dec 18, 2015, at 7:07 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Dec 18, 2015, at 5:23 PM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
For Swift 3, we're planning to phase out 'var' parameters in functions, and we're also making it so that language keywords are valid argument labels. With both of these changes pending, I have a hard time not reading:
func foo(inout x: Int)
as an argument labeled `inout` instead of an unlabeled argument bound to `x`. Once `var` is phased out, `inout` would also be the only remaining case where quoting is necessary to use a name as an argument label. The `inout` keyword has always struck me as weird, since it violates definition-follows-use—maybe we should replace it with the `&` sigil, mirroring its usage in call sites.
-1
“inout” is intended to communicate (or at least hint at) the copy-in / copy-out behavior of the argument. It is also there to enable other parameter modifiers, which can enable other more advanced parameters models in the future (e.g. rust-style borrowing).
My sentiments exactly. As I was catching up on this thread, this was almost exactly the syntax I was already considering mentioning when I encountered Erica's reply.
I don't know whether it will meet all requirements; however, from a readability perspective in both declarations and function type signatures, this syntax is the first of the suggestions that feels clear to me.
-- Tahoma
···
On Dec 21, 2015, at 11:20 AM, Ricardo Parada via swift-evolution <swift-evolution@swift.org> wrote:
On Dec 19, 2015, at 4:10 PM, Erica Sadun <erica@ericasadun.com> wrote:
What would the ramifications of the following be? Each addresses the "confusable with labeling" issue but preserve the inout keyword.
func foo(x: inout Int)
...
I think I like this one better than all the others.
I have not analyzed all the implications of having it there but it feels right.
One downside is that we do use '&' for things other than inout: pointers. If/when we do have a notion of "pass the stable address of this thing", 'inout' is not necessarily the most appropriate way to mark it.
Then again, if something has a stable address, you're not limited to getting its address using a call.
Jordan
···
On Dec 21, 2015, at 10:27 , Joe Groff <jgroff@apple.com> wrote:
On Dec 19, 2015, at 7:12 PM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Sat, Dec 19, 2015 at 7:06 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
-1 to using '&' in the declaration; it's a sigil that doesn't mean anything as is. (I was originally on the side of using 'inout' at the call site as well, i.e. "swap(inout x, inout y)", but it was considered too verbose.)
I'd actually suggest that we reconsider this. '&' at the callsite has deep associations with C semantics, and I have too frequently seen buggy code using '&x' combined with one of the C interop implicit conversions to "get a pointer" that the code stores in a variable somewhere. It is also hard to explain to people that '&x' does not do what they want in that case, "& means address-of, and it returns a pointer here, what do you mean I can't use it?"
Using `inout` at the call site seems reasonable to me. I'd bet the vast majority of `inout` parameters are really the implicit `self` of mutating methods, which already get a pass, so aside from `swap` I wonder how often `&` is in practice.
There's also a possibility that we add 'out' parameters in the future, and
if 'inout' would be spelled '&', then we would need to find another sigil
for 'out'.
We have multiple returns. Why would we ever add out parameters?
I don't want to turn this thread into a discussion about out
parameters, but one reason would be to replace
AutoreleasingUnsafeMutablePointer.
IMO we should eventually import out params from C as multiple returns.
Another one is to add labels to
the output parameters:
let (day, month, year) = parseDate()
let (year, day, month) = parseDate() // bug?
Labeled tuples seem like they could help with that, with compiler QoI to catch cases like this where you obviously permuted the return names.
let (string: boundString, int: boundInt) = labeledMultiReturn()
print(boundString)
print(boundInt)
···
On Dec 21, 2015, at 12:36 PM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org> wrote:
On Mon, Dec 21, 2015 at 10:34 AM, Joe Groff <jgroff@apple.com> wrote:
On Dec 18, 2015, at 6:52 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Fri, Dec 18, 2015 at 6:21 PM, Joe Groff <jgroff@apple.com> wrote:
On Dec 18, 2015, at 6:08 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
Chris Lattner mentioned that he wants to have a version of Rust's borrowing
syntax eventually. With this change, if we get that, then we keep a very
symmetric syntax:
func foo(x: inout T) called as foo(inout myT)
func foo(x: &T) called as foo(&myT)
func foo(x: &mut T) called as foo(&mut myT)
···
On Wed, Jan 6, 2016 at 10:42 AM, Tahoma Toelkes via swift-evolution < swift-evolution@swift.org> wrote:
+1
My sentiments exactly. As I was catching up on this thread, this was
almost exactly the syntax I was already considering mentioning when I
encountered Erica's reply.
I don't know whether it will meet all requirements; however, from a
readability perspective in both declarations and function type signatures,
this syntax is the first of the suggestions that feels clear to me.
-- Tahoma
On Dec 21, 2015, at 11:20 AM, Ricardo Parada via swift-evolution < > swift-evolution@swift.org> wrote:
On Dec 19, 2015, at 4:10 PM, Erica Sadun <erica@ericasadun.com> wrote:
What would the ramifications of the following be? Each addresses the
"confusable with labeling" issue but preserve the inout keyword.
func foo(x: inout Int)
...
I think I like this one better than all the others.
I have not analyzed all the implications of having it there but it feels
right.
Well, they don't *force* you to use labels at the use site,
allowing bugs to happen even if the API author went out of their way
and used labels.
Dmitri
···
On Mon, Dec 21, 2015 at 10:40 AM, Matthew Johnson <matthew@anandabits.com> wrote:
On Dec 21, 2015, at 12:36 PM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org> wrote:
On Mon, Dec 21, 2015 at 10:34 AM, Joe Groff <jgroff@apple.com> wrote:
On Dec 18, 2015, at 6:52 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Fri, Dec 18, 2015 at 6:21 PM, Joe Groff <jgroff@apple.com> wrote:
On Dec 18, 2015, at 6:08 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
There's also a possibility that we add 'out' parameters in the future, and
if 'inout' would be spelled '&', then we would need to find another sigil
for 'out'.
We have multiple returns. Why would we ever add out parameters?
I don't want to turn this thread into a discussion about out
parameters, but one reason would be to replace
AutoreleasingUnsafeMutablePointer.
IMO we should eventually import out params from C as multiple returns.
Another one is to add labels to
the output parameters:
let (day, month, year) = parseDate()
let (year, day, month) = parseDate() // bug?
Labeled tuples seem like they could help with that, with compiler QoI to catch cases like this where you obviously permuted the return names.
There's also a possibility that we add 'out' parameters in the future, and
if 'inout' would be spelled '&', then we would need to find another sigil
for 'out'.
We have multiple returns. Why would we ever add out parameters?
I don't want to turn this thread into a discussion about out
parameters, but one reason would be to replace
AutoreleasingUnsafeMutablePointer.
IMO we should eventually import out params from C as multiple returns.
Another one is to add labels to
the output parameters:
let (day, month, year) = parseDate()
let (year, day, month) = parseDate() // bug?
Labeled tuples seem like they could help with that, with compiler QoI to catch cases like this where you obviously permuted the return names.
let (string: boundString, int: boundInt) = labeledMultiReturn()
print(boundString)
print(boundInt)
Well, they don't *force* you to use labels at the use site,
allowing bugs to happen even if the API author went out of their way
and used labels.
Got it. Objection understood. That said, wouldn’t it be a relatively small change to require their use at the call site when the API author includes them in the return type, at least when the result is directly bound to variables?
···
On Dec 21, 2015, at 12:43 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Mon, Dec 21, 2015 at 10:40 AM, Matthew Johnson > <matthew@anandabits.com> wrote:
On Dec 21, 2015, at 12:36 PM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org> wrote:
On Mon, Dec 21, 2015 at 10:34 AM, Joe Groff <jgroff@apple.com> wrote:
On Dec 18, 2015, at 6:52 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Fri, Dec 18, 2015 at 6:21 PM, Joe Groff <jgroff@apple.com> wrote:
On Dec 18, 2015, at 6:08 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
This is the only concern I have with the current consensus. We could just re-introduce & as an ordinary unary “assignment” operator, maybe.
John.
···
On Dec 21, 2015, at 11:19 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
On Dec 21, 2015, at 10:27 , Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:
On Dec 19, 2015, at 7:12 PM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Sat, Dec 19, 2015 at 7:06 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
-1 to using '&' in the declaration; it's a sigil that doesn't mean anything as is. (I was originally on the side of using 'inout' at the call site as well, i.e. "swap(inout x, inout y)", but it was considered too verbose.)
I'd actually suggest that we reconsider this. '&' at the callsite has deep associations with C semantics, and I have too frequently seen buggy code using '&x' combined with one of the C interop implicit conversions to "get a pointer" that the code stores in a variable somewhere. It is also hard to explain to people that '&x' does not do what they want in that case, "& means address-of, and it returns a pointer here, what do you mean I can't use it?"
Using `inout` at the call site seems reasonable to me. I'd bet the vast majority of `inout` parameters are really the implicit `self` of mutating methods, which already get a pass, so aside from `swap` I wonder how often `&` is in practice.
One downside is that we do use '&' for things other than inout: pointers. If/when we do have a notion of "pass the stable address of this thing", 'inout' is not necessarily the most appropriate way to mark it.
+1 for having to mark calls to `inout` parameters with `inout` rather than
`&`, `&` is well entrenched in its C usage.
For repurposing of `&`; if you had library functions:
class Reference<T> {
let value: T
init(value: T) { self.value = value }
}
class MutableReference<T> {
var value: T
init(value: T) { self.value = value }
}
Then when you obtained something from a C library you wrapped it:
let rect = MutableReference(CGRectMake(0,0,0,0))
Wouldn't that cover most use cases and be simpler than implementing a new
`&`?
The above classes would also have general purpose usage reference
semantics rather than `inout` semantics, e.g.:
let array = [MutableArray(1), MutableArray(2)]
`array` can be passed to threads, used in closures, etc. without the copy
in and copy out semantics being surprising and unpredictable.
···
On Thursday, 7 January 2016, Trent Nadeau via swift-evolution < swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:
+1
Chris Lattner mentioned that he wants to have a version of Rust's
borrowing syntax eventually. With this change, if we get that, then we keep
a very symmetric syntax:
func foo(x: inout T) called as foo(inout myT)
func foo(x: &T) called as foo(&myT)
func foo(x: &mut T) called as foo(&mut myT)
On Wed, Jan 6, 2016 at 10:42 AM, Tahoma Toelkes via swift-evolution < > swift-evolution@swift.org> wrote:
+1
My sentiments exactly. As I was catching up on this thread, this was
almost exactly the syntax I was already considering mentioning when I
encountered Erica's reply.
I don't know whether it will meet all requirements; however, from a
readability perspective in both declarations and function type signatures,
this syntax is the first of the suggestions that feels clear to me.
-- Tahoma
On Dec 21, 2015, at 11:20 AM, Ricardo Parada via swift-evolution < >> swift-evolution@swift.org> wrote:
On Dec 19, 2015, at 4:10 PM, Erica Sadun <erica@ericasadun.com> wrote:
What would the ramifications of the following be? Each addresses the
"confusable with labeling" issue but preserve the inout keyword.
func foo(x: inout Int)
...
I think I like this one better than all the others.
I have not analyzed all the implications of having it there but it feels
right.
That, or require either the label be explicit or that the binding name match the label. 'let (foo: foo, bar: bar)' would be a bit unfortunate.
-Joe
···
On Dec 21, 2015, at 11:07 AM, Matthew Johnson <matthew@anandabits.com> wrote:
On Dec 21, 2015, at 12:43 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Mon, Dec 21, 2015 at 10:40 AM, Matthew Johnson >> <matthew@anandabits.com> wrote:
On Dec 21, 2015, at 12:36 PM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org> wrote:
On Mon, Dec 21, 2015 at 10:34 AM, Joe Groff <jgroff@apple.com> wrote:
On Dec 18, 2015, at 6:52 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Fri, Dec 18, 2015 at 6:21 PM, Joe Groff <jgroff@apple.com> wrote:
On Dec 18, 2015, at 6:08 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
There's also a possibility that we add 'out' parameters in the future, and
if 'inout' would be spelled '&', then we would need to find another sigil
for 'out'.
We have multiple returns. Why would we ever add out parameters?
I don't want to turn this thread into a discussion about out
parameters, but one reason would be to replace
AutoreleasingUnsafeMutablePointer.
IMO we should eventually import out params from C as multiple returns.
Another one is to add labels to
the output parameters:
let (day, month, year) = parseDate()
let (year, day, month) = parseDate() // bug?
Labeled tuples seem like they could help with that, with compiler QoI to catch cases like this where you obviously permuted the return names.
let (string: boundString, int: boundInt) = labeledMultiReturn()
print(boundString)
print(boundInt)
Well, they don't *force* you to use labels at the use site,
allowing bugs to happen even if the API author went out of their way
and used labels.
Got it. Objection understood. That said, wouldn’t it be a relatively small change to require their use at the call site when the API author includes them in the return type, at least when the result is directly bound to variables?