This is some sort of a cross-post from another thread ["automatic protocol
forwarding"] — for anyone who wants to follow, I recommend to read
https://kotlinlang.org/docs/reference/classes.html
<https://kotlinlang.org/docs/reference/classes.html>
The idea of "function-like class declaration" has been introduced here by Joe
Groff, but apparently, its benefits have been underestimated.
> If you feel Kotlin’s approach is better please respond to the memberwise
> initialization thread with some examples written in both Kotlin and in Swift
> using the memberwise initialization feature I am proposing to demonstrate how
> and why you think it is better.
> Here is Kotlin:
> class Person constructor(firstName: String, lastName: String) {
> }
That is a bad start — do you want to make Kotlin look worse than it is? You can
just write "class Person(firstName: String, lastName: String)", the other
syntax merely exists to allow designated constructors with special access
restrictions.
> Here is Swift under my proposal:
> class Person {
> var firstName: String
> var lastName: String
> // compiler synthesizes memberwise init
> }
>
> However, my proposal gives you a lot of additional flexibility:
I deny that, and even if it is true, there is a price to pay — and that is more
than the lines of code that are required...
> 1. It interacts well with access control
Better than Kotlin? Please prove this.
> 2. Partial memberwise initialization is possible
The same with Kotlin — and imho at least as easy
> 3. It allows memberwise initializers to accept non-memberwise parameters to
> initialize private state
I think this can be achieved with less effort using function-like class
declaration (afair Joe already gave an example)
> 4. More than one memberwise initializer is possible
Kotlin has no need for memberwise initializers at all, and I see this as a big
advantage
> 5. Memberwise initialization of properties with declaration modifiers,
> behaviors / delegates is possible
https://kotlinlang.org/docs/reference/delegated-properties.html
<https://kotlinlang.org/docs/reference/delegated-properties.html>
(afaik this is not only possible, it's handled by the current compiler for a
long time)
> And probably more. My approach was to design a solution that fits into the
> current Swift language and is orthogonal to other language features as much
> as possible.
Afaics there not much room left for the promised additional flexibility… and
the problem with default values for constants just doesn't exist in Kotlin at
all.
I neither state your proposal is bad, nor that we should simply copy an
existing solution, but even as a big fan of Swift, I have to admit that Kotlin
(which I probably will never use in real projects) clearly performs better in
this area:
It's more concise, it doesn't need "required" nor "convenience", it offers an
intuitive syntax for forwarding and it is easy to grasp.
I know that I'm not just challenging your own, personal ideas here, and have no
illusions about the outcome of this bold move — but it is my honest opinion
this proposal might (in total) be better than the status quo, but is inferior
to Kotlin in every aspect (whereas the current scheme has the edge of
familiarity on its side).
Best regards,
Tino_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
