[swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

[Kevin Ballard]

On Thu, Jan 7, 2016, at 03:11 PM, Matthew Johnson wrote:
>
>> On Jan 7, 2016, at 3:31 PM, Kevin Ballard <kevin at sb.org> wrote:
>>
>> On Thu, Jan 7, 2016, at 07:12 AM, Matthew Johnson wrote:
>>>> As for my concern, it's with the following rule:
>>>>
>>>>> If the initializer body assigns to a var property that received
>>>>> memberwise initialization synthesis report a warning. It is
>>>>> unlikely that overwriting the value provided by the caller is the
>>>>> desired behavior.
>>>>
>>>> I understand why you put this in there, but this is a warning that
>>>> cannot be suppressed and will make it impossible to use a
>>>> memberwise initializer for perfectly legitimate cases where you do
>>>> in fact want to mutate the property after it's been assigned to.
>>>
>>> For normal initializers I agree with you.  However, I think it’s a
>>> reasonable for callers to assume that if you expose a property via
>>> memberwise initialization the post-initialization value will match
>>> the value they provide.  This warning is intended to alert you to
>>> the fact that you are violating that reasonable assumption.
>>
>> I think that's a reasonable assumption in many cases, but I don't
>> like the fact that the feature cannot be used at all in the rare case
>> where it actually makes sense to mutate the value.
>>
>>> Do you have an example of where you would want a caller to
>>> initialize a property, but then overwrite the value they provide
>>> *during initialization*?
>>
>> Sure, how about something like a Rect type that always guarantees
>> it's in "standard" form (e.g. no negative sizes):
>>
>> struct StandardRect {    var origin: CGPoint    var size: CGSize {
>> didSet {            // ensure standardized form here        }    }
>>
>> memberwise init(...) {        if size.width < 0 {            origin.x
>> += size.width            size.width = -size.width        }        if
>> size.height < 0 {            origin.y += size.height
>> size.height = -size.height        }    } }
>
> This is a good example.  Thanks!
>
> I think cases like this will be rare so I still think a warning is a
> good idea.  Something like -Wno-overwrite-memberwise-init would allow
> it to be suppressed in cases where you actually do intend to do this.
> Would that satisfy you?

No. It's not appropriate to have the only way to suppress a warning
on perfectly legal code to be passing a flag to the swiftc
invocation. Especially because we have no precedent yet for even
having flags like that.

What's wrong with the suggestion to make the warning behave the same way
as dead store warnings (e.g. warn if the property is overwritten without
any prior reads)? We already have logic for doing this kind of analysis.

-Kevin Ballard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160107/14082988/attachment.html>