[swift-evolution] Language syntax proposal - shorthand for super invocations

[James Campbell]

What if we could use the compiler to help ?

super(#args)

#args being the arguments passed to the current function.

*___________________________________*

*James⎥Lead Engineer*

*james at supmenow.com <james at supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Tue, Feb 9, 2016 at 9:09 AM, Radosław Pietruszewski <
swift-evolution at swift.org> wrote:

> `super` would only exhibit the proposed behavior when it is a standalone
> token. The expressions `super` and `super.widgetCount` are both permitted
> and both are exactly equivalent.
>
> To express what you're suggesting with the extension (either with the
> current grammar or the proposed feature), it would be:
>
> override var widgetCount: Int {
>     return super.widgetCount.widgetCount + 5
> }
>
> Your example is not ambiguous because `super.widgetCount` only ever means
> the value of the widgetCount property in the superclass; `super` is not
> first evaluated to the aforementioned value and then `widgetCount` invoked
> on that result, since the entire `super.widgetCount` would be treated
> atomically, conceptually, as it is now.
>
>
> Maybe, but I don’t like it. Even if the compiler can disambiguate, this
> will still be confusing.
>
> Without offering an opinion either way on this proposal, I will note that
> the alternative suggestion of `super()` does not suffer from this ambiguity.
>
>
> You’re right! I’d be cool with `super()`.
>
> — Radek
>
> On 09 Feb 2016, at 09:44, Petroules Jake <Jake.Petroules at theqtcompany.com>
> wrote:
>
> `super` would only exhibit the proposed behavior when it is a standalone
> token. The expressions `super` and `super.widgetCount` are both permitted
> and both are exactly equivalent.
>
> To express what you're suggesting with the extension (either with the
> current grammar or the proposed feature), it would be:
>
> override var widgetCount: Int {
>     return super.widgetCount.widgetCount + 5
> }
>
> Your example is not ambiguous because `super.widgetCount` only ever means
> the value of the widgetCount property in the superclass; `super` is not
> first evaluated to the aforementioned value and then `widgetCount` invoked
> on that result, since the entire `super.widgetCount` would be treated
> atomically, conceptually, as it is now.
>
> I can see that the fact that `super` itself does refer to an instance of T
> could be problematic for properties. For functions, if written as `super()`
> or `super(...)` so this should be OK and unambiguous. Perhaps the shorthand
> syntax could be limited to functions since they tend to be longer and in
> greater need of something like this in the first place.
>
> On Feb 9, 2016, at 12:28 AM, Radosław Pietruszewski <radexpl at gmail.com>
> wrote:
>
> I want to say +1.
>
> Ruby does this and it works really nicely.  While not a big deal in simple
> cases, when a method has lots of arguments, it’s just really noisy.
>
> There’s a problem though. If `super` means both “call the superclass’s
> implementation of this method”, and “the superclass”, there’s a potential
> for ambiguity.
>
> Say:
>
> override var widgetCount: Int {
>     return super.widgetCount + 5
> }
>
>
> And:
>
> extension Int {
>     var widgetCount: Int { return 10 }
> }
>
>
> Does super.widgetCount call the superclass’s `widgetCount`, or does it
> call the superclass’s implementation of the same getter, then call
> `widgetCount` on the returned Int?
>
> — Radek
>
> On 09 Feb 2016, at 06:31, Petroules Jake via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hello,
>
> I have a language syntax proposal. I've read the Swift evolution
> guidelines and hopefully this is the proper way to start. So, my proposal
> is:
>
> Permit a shorthand syntax for invoking the supertype implementation of a
> property or function. A single statement 'super' is equivalent to invoking
> the supertype implementation, forwarding the arguments unchanged, and
> returning the result. For example, the following samples:
>
> override func mouseEntered(theEvent: NSEvent) {
>     super
>     handleMouseEvent(theEvent)
> }
>
> override func specialValue(key: String) -> Int {
>     return super + 1
> }
>
> override var widgetCount: Int {
>     return super + 5
> }
>
> are exactly equivalent to the following samples:
>
> override func mouseEntered(theEvent: NSEvent) {
>     super.mouseEntered(theEvent)
>     handleMouseEvent(theEvent)
> }
>
> override func specialValue(key: String) -> Int {
>     return super.specialValue(key) + 1
> }
>
> override var widgetCount: Int {
>     return super.widgetCount + 5
> }
>
> Alternatives/complementary ideas:
>
> - Require `super()` or `super(...)` syntax for invocations which are
> function calls, for consistency with other function calls in the language
> and/or to indicate that arguments are forwarded
>
> Looking forward to your feedback.
>
> Thanks!
> --
> Jake Petroules - jake.petroules at theqtcompany.com
> Consulting Services Engineer - The Qt Company
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> --
> Jake Petroules - jake.petroules at theqtcompany.com
> Consulting Services Engineer - The Qt Company
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160209/aebd7e47/attachment.html>