[swift-evolution] Proposal SE-0009 Reconsideration

[Vladimir.S]

IMO nice idea, but I see that this could be confused with using enum values:

enum E {
     case one
     case two

     static func foo(e: E) {}
}

struct S {
     var one = 100
     ...

     func f() {
         E.foo(.one)
         print(one) // ? print(.one)
	someFunc(.something) // is it enum or property of this struct S?
     }
}

Probably another variants like `:` symbol could be suggested:

     func f() {
         E.foo(.one)
         print(:one)
	someFunc(:something)
     }
But also not ideal.

But all this just a discussions - there was clear opinion of core team 
posted that Swift should not have requirement to explicitly decorate type 
properties inside code (explicit `self.` or similar). So, someone who wants 
to use explicit 'self.' - can use it. Others - will not use.

On 26.05.2016 22:26, Paul Ossenbruggen wrote:
> Since this keeps coming up, it seems that something would be good here.
> Perhaps this has been explored before but why can’t we just use dot without
> the word “self", to indicate self?
>
> classDotIsSelf
> {
>     funcp() -> String{
>         return"self p"
>     }
>
>
>
>     funcg() {
>         print(.p()) // print “self p"
> print(p)// error undefined
>         letp = "local p"
>         print(p) // print “local p"
>         print(.p())// print “self p”
>     }
>
>
>
>     classfunck() -> String
>     {
>
>         return "self k"
>
>     }
>
>
>
>     classfuncj() {
>         print(.k()) // print “self k"
> print(k)// error undefined
>         letk = "local k”
>         print(k) // print “local k"
>         print(.k()) // print “self k"
>     }
> }
>
> Self could still be used but “self.” or “.” would be required to access self.
>
> Rationale:
> • since self is referenced quite often in classes it should be very short
> and easy to type
> • less cluttered than self being everywhere but not ambiguous. whether you
> mean the local variable or the instance.
> * Already very similar notation for enums where you leave off the entity
> name when it can be implied.
> • Does not interfere, that I could see, with other uses of dot. (I am sure
> I will be corrected if wrong, but putting it out there because I want to
> know why :-)
> • Feels quite intuitive and easy to understand.
> * Make Swift safer because it eliminates potential ambiguity as has been
> pointed out many times.
> • Other characters would be less natural than dot.
> • In the IDE, hitting dot would immediately bring up self items as choices.
>
>
>
>