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

[Kevin Ballard]

On Fri, Jan 8, 2016, at 12:56 AM, Thorsten Seitz wrote:
>
>> Am 08.01.2016 um 00:41 schrieb Kevin Ballard via swift-evolution <swift-
>> evolution at swift.org>:
>>
>> 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:
>>>>> 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!
>
> Actually I do not like this example for several reasons: (1) I would
> make the rectangle an immutable type with let properties, (2) the
> didSet already seems to do what is encoded in the memberwise init, so
> this seems to be redundant, (3) the memberwise init is so complex that
> having the automatic initialization feature is not really worth it for
> this example, especially as it seems to require using var properties
> instead of let properties to do the overwriting.

1) Why would you make it immutable? That helps nothing and only serves
   to make the type harder to use. Structs should _rarely_ be immutable,
   you should always default to mutable and only make things immutable
   if there's a good reason for it. If the struct itself is in an
   immutable position then it inherits the immutability, which handles
   all of the reasons why you might otherwise default to immutable.

2) didSet isn't triggered in init. There's no redundancy.

3) You really really want var properties anyway, it's pointless to use
   let properties.

>>> 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.
>
>
> I think this would not be sufficient, because this would not allow
> overwriting a property based on the value of another property which
> might be necessary as well.

That seems much less likely to be necessary, because if you're doing
that, then you're completely ignoring one of your parameters.

> Actually isn’t this what happens in your example? The property origin
> is overwritten without being read, so this would generate the warning,
> or did I understand something wrong?

Origin is being modified. Modification reads it first. `x += 2` reads
`x` before writing to it.

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