[Review] SE-0018 Flexible Memberwise Initialization


(Alex Burke) #1

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,