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

Fri Jan 8 21:00:27 CST 2016

"
This is not allowed under the proposal.  If you declare a parameter with an
external label matching a synthesized parameter an error will result.
Allowing it would be one way to solve the default for `let` problem but it
would require duplicating the parameter declaration and default value in
every memberwise init.
"

Possibly you can then rethink this issue. Is more simpler than a new
operator. Also I see no reason to duplicate the parameter declaration in
other memberwise init. Less is more.

Em sex, 8 de jan de 2016 às 21:09, Matthew Johnson <matthew at anandabits.com>
escreveu:

> On Jan 8, 2016, at 2:40 PM, Wallacy via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I like the idea of the proposal (not 100%) but i really dislike the
> "Future enhancements" part:
>
> *@default* is unnecessary in my opinion, i think just write the "future"
> variable declaration ("memberwised") and put the default value is enough:
>
> struct S {
>     let s: String
>     let i: Int
>
>     // user declares:
>     memberwise init(s: String = "hello",...) {}
>
>     // compiler synthesizes:
>     init(s: String = "hello", i: Int) { // because s: String matches the sintaxe, so the compiler will not (re)synthesize.
>         /* synthesized */ self.s = s
>         /* synthesized */ self.i = i
>     }
> }
>
>
>
>
> This is not allowed under the proposal.  If you declare a parameter with
> an external label matching a synthesized parameter an error will result.
> Allowing it would be one way to solve the default for `let` problem but it
> would require duplicating the parameter declaration and default value in
> every memberwise init.
>
> *memberwise properties* and *@nomemberwise* are too much trouble for
> little gain.  Hand write the init by itself will be more easy and clear.
>
> The fist part when the proposal focuses only on the automation of (maybe
> only undeclared) variables on init using "..." placeholder as insertion
> point, I believe that can be a nice feature.
>
>
> Em sex, 8 de jan de 2016 às 18:13, Thorsten Seitz via swift-evolution <
> swift-evolution at swift.org> escreveu:
>
>> Am 08.01.2016 um 19:58 schrieb Kevin Ballard via swift-evolution <
>> swift-evolution at swift.org>:
>>
>> 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.
>>
>>
>> Hmm, food for thought… guess I still haven’t completely understood
>> Swift’s handling of immutability… thanks for pointing that out!
>>
>> 2) didSet isn't triggered in init. There's no redundancy.
>>
>>
>> You are right, of course. I forgot that when I wrote the mail.
>>
>> 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.
>>
>>
>> I stand corrected.
>>
>> -Thorsten
>>
>>
>>
>> -Kevin Ballard
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>  _______________________________________________
> 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/20160109/64072862/attachment.html>