Caught red handed not having gone through the alternatives! I'm not sure
the listed negatives are too bad though. Impact on existing source, in
particular, why is that an issue? Code migration has solved every breaking
change so far. As for oldValue, yes, I think that should be changed as
well. Not sure why that is a con. Agreed it makes it more verbose but also
gives more clarity and the verbosity is negligible and I would say better
than hidden compiler magic.
The need for the proposed solution feels a bit like a monkey-patch on top
of a system that shouldn't need that monkey patch in the first place. That
said, the proposal, were it accepted as-is, would be a welcome change and
thanks for writing it up.
On Tue, Dec 15, 2015, 9:41 PM Marc Knaup <email@example.com> wrote:
That approach is mentioned in "Alternatives considered".
On Dec 16, 2015 03:39, "Dennis Lysenko" <firstname.lastname@example.org> > wrote:
Other possible solution: why not just remove the default "newValue" and
force the user to manually specify it instead?
On Tue, Dec 15, 2015, 6:02 PM Marc Knaup via swift-evolution < >> email@example.com> wrote:
I would like to propose yielding a warning when a property's getter is
used from within its setter implicitly without using "self.".
This can lead to programming errors which are very easy to miss and lead
to unexpected behavior at runtime.
Check out the full proposal here:
swift-evolution mailing list