[swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration

[Allen Ding]

Thanks Erica. I just read the post and I still can't help wonder if things
are that bad?

The post doesn't mention much about C-pointers other than calling
inOutParameter parameter a pointer (it isn't) that doesn't need to be
dereferenced. It does seem like the compiler helps catch any usage errors
as intended. But I don't see how something detrimental, whether in terms of
grokking Swift or an unintended usage consequence arises in this scenario.

- Allen Ding


On Sat, Jan 30, 2016 at 8:25 AM, Erica Sadun <erica at ericasadun.com> wrote:

>
> On Jan 29, 2016, at 5:14 PM, Allen Ding <allen at snappymob.com> wrote:
>
> 1. Is there some data or real world story to support (1)? I've never had
> the same expectations even when first encountering Swift and definitely
> less so after reading the documentation, because the concept and syntax for
> inout and & is not really profound. And even if I did *pointers!*, I would
> figure things out rather quickly because nothing else would work.
>
>
> Going from personal experience?
>
> http://ericasadun.com/2015/04/10/swift-var-parameters/
>
> -- E, "professionally dense"
>
>
> (2. I don't have experience with Rust, so there would need to be some
> details on why being more Rust like is a good thing :)
>
> On Sat, Jan 30, 2016 at 7:50 AM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> The great advantages are:
>>
>> 1. It removes a potentially confusing overlap with C-style expectations.
>> People see & and think "POINTERS!", which is not how things work in Swift
>> with copy-back.
>> (2. It eventually frees up &, so we can have more Rust)
>>
>> -- E
>>
>> On Jan 29, 2016, at 4:42 PM, Charles Kissinger <crk at akkyra.com> wrote:
>>
>> Sorry, I wasn’t clear at all there. I was thinking of the most common
>> case where there is either only one parameter or the inout parameter is the
>> first one. Then there will typically be no argument label involved at the
>> call site. In that case ‘inout’ will be the first word inside the parens at
>> the call site (assuming it replaces ‘&’). If it also is kept in its current
>> position in function declarations, it will be in that same leading position
>> in declarations and (I’m assuming) people will have an easy time
>> remembering where to put it.
>>
>> When there is a label involved, it is a different story. I was
>> implicitly, and probably wrongly, assuming that would be a much less common
>> case in practice. A poorly worded, and probably poorly reasoned, argument
>> on my part, though I still don’t see any great advantage to replacing ‘&'.
>>
>> —CK
>>
>> On Jan 29, 2016, at 2:13 PM, Erica Sadun <erica at ericasadun.com> wrote:
>>
>>
>> On Jan 29, 2016, at 3:04 PM, Charles Kissinger <crk at akkyra.com> wrote:
>> The related idea of replacing ‘&’ with ‘inout’ at the call site seems
>> completely contradictory to this proposal. Developers would then have to
>> remember that the ‘inout’ goes before the argument at the call site but
>> after it in the function definition. That seems like a constant source of
>> mis-typings and something that would be viewed as an inconsistency in the
>> language. Or do people want to put it after the argument name at the call
>> site too? It seems a little like change just for the sake of change, IMO.
>>
>>
>> If you have a function
>>
>> f(x: Int) {}
>>
>> you call it with f(8), and potentially f(x: 8). Even when labeled, the 8
>> value is to the right of the colon.
>>
>> Now consider
>>
>> f(x: inout Int) {}
>>
>> you call it with f(&y) or f(inout y), and with a label, you'd call it
>> f(x: &y) or f(x: inout y).
>>
>> It seems  consistent to me.
>>
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160130/9febbea2/attachment.html>