On Jan 8, 2016, at 2:40 PM, Wallacy via swift-evolution < >> swift-evolution@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.
Em sex, 8 de jan de 2016 às 18:13, Thorsten Seitz via swift-evolution < >> swift-evolution@swift.org> escreveu:
Am 08.01.2016 um 19:58 schrieb Kevin Ballard via swift-evolution < >>> swift-evolution@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution