[swift-evolution] Proposal: Re-instate mandatory self for accessing instance properties and functions

[David Rodrigues]

Hi Pierre,

there's actually a proposal to do that regarding implicit self in a closure
here:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002628.html
.

- David

2015-12-16 15:57 GMT+00:00 Pierre Monod-Broca via swift-evolution <
swift-evolution at swift.org>:

> -1 also for reasons already listed.
>
> I would even like ways to have more implicit self, like method cascading,
> closure binding, implicit self in a closure if self is explicitly captured,
> etc…
>
> --
> Pierre
>
> Le 16 déc. 2015 à 14:55, Taras Zakharko via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
> I think the most important advantage of explicit self is that it vastly
> simplifies the scoping rules of the language as it moves the instance scope
> into a clearly recognisable construction. As far as I am concerned, self
> should be mandatory. However, I can also understand that sometimes it might
> get a bit repetitive (especially when initialising state). This thread is
> getting a bit large, so sorry if I missed, but did anyone already suggest
> to introduce a scope operator, which would bind a particular instance to
> the top of the variable scope. Such operator could be integrated into the
> existing do, e.g.
>
> do with self { // or with self do
>    x = 1
>    y = 2
> }
>
> similarly
>
> do with obj {
>    x = 1
>    y= 2
> }
>
> This has the benefit of keeping the scoping rules simple, preventing
> clashes between the instance scope and the block/function/global scope,
> while retaining the possibility to use the ‘more readable’ form if needed.
> Furthermore, it can be also seen as a neat logical ‘grouping'  construct
> that aids the programmer in understanding the code better.
>
> Again, I apologise if this suggestion was already made, I might have
> overlooked it.
>
> Best,
>
>  Taras
>
>
> -DW
>
>
> On Dec 15, 2015, at 3:46 PM, Honza Dvorsky via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hi all,
>
> I've been following the thread from the beginning and some great arguments
> have been layed out. As far as I understand, this proposal would lead to
> fewer correctness bugs (referring to a different variable due to implicit
> self, has happened to me twice in the last couple of months, was very hard
> to track down).
>
> The disadvantages of this are only verbosity. But, from the design
> principles of Swift (as I understand them), correctness is preferred over
> making the language concise, especially when those two are in conflict,
> just like here.
>
> I support the proposal, because it would lead to fewer bugs at only the
> cost of extra few characters. Again, I've been bitten by implicit self a
> couple times before and those bugs are hard to track down. And the
> readability of the code in code reviews, to me, is another huge advantage,
> possibly leading to more correctness bugs caught early.
>
> I understand and appreciate the disadvantages, but again, I believe we
> should prefer correctness over conciseness, as explicitly stated by the
> Swift design principles.
> On Tue, Dec 15, 2015 at 11:28 PM Slava Pestov via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Hi all,
>>
>> I don't see anyone lay out how this proposal can interact with nested
>> types and such. There's a fair amount of complexity in Swift with what you
>> can do by nesting things inside of each other, so the simple conceptual
>> model of "locals are unqualified, instance variables have a self. prefix"
>> doesn't seem to generalize.
>>
>> Will I need to qualify associated types with the protocol or type name to
>> refer to them? What about generic type parameters, they're sort of like
>> "instance variables" too.
>>
>> What about class methods that want to call each other? Do they need the
>> explicit 'self', or an explicit class name prefix? The latter changes
>> semantics if the class method is overridden in a subclass.
>>
>> If we ever add the ability for an inner type to capture stored properties
>> from the outer type, how do you reference properties of the outer type? I
>> guess the problem has to be solved anyway to refer to an outer "self"
>> explicitly, but qualifying everything with OuterType.self.foo kind of
>> defeats the purpose of inner types altogether.
>>
>> I'm not sure I buy the readability arguments in favor of this approach.
>> It seems the languages where explicit 'self' was adopted did it mostly by
>> accident, or because of implementation concerns. In Python for instance,
>> there's no way for assignment to modify a binding in an outer scope, so
>> 'foo = bar' always sets a local named 'foo', IIRC. So explicit self is
>> needed there. Greg Parker explains earlier in this thread by explicit self
>> was chosen for Objective-C, and it wasn't readability.
>>
>> Slava
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/20151216/a84112ba/attachment.html>