[swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization
Alex Burke
alexjeffburke at gmail.com
Sun Jan 10 10:09:52 CST 2016
Hi,
Please forgive the intrusion - I'm somewhat of a lurker but I've been
following Swift evolution and particularly this discussion with interest. I
primarily write in other languages (JS and Python) but see Swift as finally
allowing me to pick up native app development.
* what is your evaluation of the proposal?
I write a lot of JavaScript and have introduced a good few bugs in due to
typos when assigning variables in initializing functions. I think anything
that reduces the boilerplate is a win.
That being said, I take seriously the concern about reordering the
variables and that breaking previous synthesised initializer functions. The
way of getting around this in JS is to pass down a dictionary of arguments,
but that's is a bit of a hack around the language. Python is much better
here, with the **kwargs calling convention - but most importantly, Python 3
introduced keyword only args (anything after an * in the function
definition) that *cannot* be called positionally.
I think something like would go a significant way to addressing concerns
about initializers created by this proposal.
* is the problem being addressed significant enough?
As mentioned above, repetitive boilerplate is a source of bugs and as
someone mentioned previously you become blind to things once repeated
enough.
* does this proposal fit well with swift?
Reducing boilerplate by using all the tools such as the compiler and type
information seems to be a very Swift approach.
* compared to other languages
As mentioned, I think the closet language level feature is actually
Python calling conventions for functions, and that is something I think
becomes generally an incredibly useful feature.
* effort in review
I have tried to follow all the discussion and have read the proposal. As I
say I'm somewhat of a Swift outsider but have have an interest in language
design. Of the alternatives presented, I think the tuple assignment to
'members' has merit in the calling convention, but I'd argue against a
special internal property unless it was merely something like a special
tuple that on assignment updated the instance properties of the object. But
it was that line of thinking that led to Python keyword only args which I
think is more flexible.
Thanks for your time and hope this is useful, Alex J Burke,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160110/f63420c3/attachment.html>
More information about the swift-evolution
mailing list