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

Tue Feb 9 05:21:32 CST 2016

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 at 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 at supmenow.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:jake.petroules at theqtcompany.com>
>>>> Consulting Services Engineer - The Qt Company
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>> 
>> -- 
>> Jake Petroules - jake.petroules at theqtcompany.com <mailto:jake.petroules at theqtcompany.com>
>> Consulting Services Engineer - The Qt Company
>> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/50906f8e/attachment.html>