[swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization
品雪
pinxue at gmail.com
Fri Jan 8 22:54:40 CST 2016
This proposal recalls me some Java memory. How about to borrow the instance
fields init-expo and initializer rule and save one keyword.
Java language has class initializer and instance initializer:
class MyClass {
private static String classField = "foo";
private String instanceField = "bar";
static { ... } // class initalizer
{ ... }
MyClass() { } // constructor
}
init expr of class fields will be combined with class initializer, it will
be called when class is loading.
init expr of instance fields will be combined with instance initializer and
be called by every constructor.
On Sat, Jan 9, 2016 at 11:00 AM, Wallacy via swift-evolution <
swift-evolution at swift.org> wrote:
> "
> 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
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
--
Best Regards!
Yang Wu
--------------------------------------------------------
Location: Pudong, Shanghai, China.
EMail : pinxue at gmail.com
Website: http://www.time2change.mobi http://rockplayer.com
Twitter/Weibo : @pinxue
<http://www.pinxue.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160109/b6707c07/attachment.html>
More information about the swift-evolution
mailing list