Language syntax proposal - shorthand for super invocations

jakepetroules · 2016-02-09T05:31:47.000Z

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@theqtcompany.com<mailto:jake.petroules@theqtcompany.com>
Consulting Services Engineer - The Qt Company

Radek_Pietruszewski · 2016-02-09T08:28:54.000Z

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@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@theqtcompany.com <mailto:jake.petroules@theqtcompany.com>
Consulting Services Engineer - The Qt Company

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Brent_Royal-Gordon · 2016-02-09T08:43:30.000Z

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?

Without offering an opinion either way on this proposal, I will note that the alternative suggestion of `super()` does not suffer from this ambiguity.

···

--
Brent Royal-Gordon
Architechies

jakepetroules · 2016-02-09T08:44:33.000Z

`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@gmail.com<mailto:radexpl@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@swift.org<mailto:swift-evolution@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@theqtcompany.com<mailto:jake.petroules@theqtcompany.com>
Consulting Services Engineer - The Qt Company

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Jake Petroules - jake.petroules@theqtcompany.com<mailto:jake.petroules@theqtcompany.com>
Consulting Services Engineer - The Qt Company

Radek_Pietruszewski · 2016-02-09T09:09:58.000Z

`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@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@gmail.com <mailto:radexpl@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@swift.org <mailto:swift-evolution@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@theqtcompany.com <mailto:jake.petroules@theqtcompany.com>
Consulting Services Engineer - The Qt Company

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Jake Petroules - jake.petroules@theqtcompany.com <mailto:jake.petroules@theqtcompany.com>
Consulting Services Engineer - The Qt Company

James_Campbell · 2016-02-09T10:39:08.000Z

What if we could use the compiler to help ?

super(#args)

#args being the arguments passed to the current function.

···

*___________________________________*

*James⎥Lead Engineer*

*james@supmenow.com <james@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@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@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@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@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@theqtcompany.com
Consulting Services Engineer - The Qt Company

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Jake Petroules - jake.petroules@theqtcompany.com
Consulting Services Engineer - The Qt Company

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Radek_Pietruszewski · 2016-02-09T11:21:32.000Z

Now you have two new/magic behaviors:

- `super` meaning “super.thisMethod”, and
- #args copying the arguments of the current call

While `#args` may possibly be useful somewhere, it seems orthogonal to this proposal, and it seems simpler to go with `super()`.

— Radek

···

On 09 Feb 2016, at 11:39, James Campbell <james@supmenow.com> wrote:

What if we could use the compiler to help ?

super(#args)

#args being the arguments passed to the current function.

___________________________________

James⎥Lead Engineer

james@supmenow.com <mailto:james@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@swift.org <mailto:swift-evolution@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@theqtcompany.com <mailto:Jake.Petroules@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@gmail.com <mailto:radexpl@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@swift.org <mailto:swift-evolution@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@theqtcompany.com <mailto:jake.petroules@theqtcompany.com>
Consulting Services Engineer - The Qt Company

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Jake Petroules - jake.petroules@theqtcompany.com <mailto:jake.petroules@theqtcompany.com>
Consulting Services Engineer - The Qt Company

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution