[swift-evolution] Notes from Swift core team 2016-04-20 design discussion

[Vladimir.S]

"Another approach would be to introduce a new dynamictype keyword that 
doesn’t need to be accessed as a member of self, and keep Self the way it 
is.  Self should work in structs as a type alias."

So, could you clarify, do you suggest to introduce dynamictype keyword 
instead of "self.dynamicType" ? (In addition to remove .self on type and 
.Self for instance)

And to leave Self just as placeholder for current type i.e. "the class 
there this is declared"  ?

Just want to clarify. Let's review this code:

protocol Proto {
     func z() -> Self
     func z(s: Self)
}

class X: Proto {
     required init () {}
     func x() -> Self { return self.dynamicType.init() }
     func z() -> Self { return self }
     func z(s: X) {}
}


How should it looks like in Swift 3.0 ? :

protocol AP {
     func z() -> dynamictype
     func z(s: Self)
}

class X: AP {
     required init () {}
     func x() -> dynamictype { return dynamicType.init() }
     func z() -> dynamictype { return self }
     func z(s: X) {} // ? Don't we want to have Self here ?
}


Do you support to extend Self to be used in class methods declarations to 
behave just like in protocol i.e. as "placeholder for defined class" ?

So we can have in class:
     func z(s: Self) {}

Do you support to rename Self -> #Self ?

Thank you for answers.


On 21.04.2016 18:58, Alex Martini via swift-evolution wrote:
> To help keep proposals moving forward, the Swift core team has set aside
> some time specifically for design discussions of upcoming proposals.  Below
> are some rough notes from the yesterday's discussion.
>
> These are informal comments, intended to guide the proposals in directions
> that draw constructive feedback. You are welcome to ignore the
> feedback, agree with it, or disagree with it.  As always, the formal
> decision doesn't happen until after the review period ends.
>
>
>       SE-0068: Expanding Swift Self to class members and value types
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md
>
> We have one keyword left in the language, dynamicType, which is camel
> cased. This proposal renames it to Self instead.
>
> In a static function today, self.dynamicType will give you a metatype but
> the non-member Self will not. The most useful reason to reference it is to
> call an initializer. It makes accessing the metatype weirder. It’s
> not Self.Type; that’s a type — you have to spell it Self.type.
>
> Quiz time! What do each of the permutations mean?
>
> Self.self
> self.Self
> Self.Self
> self.self
>
> The number of capital letters gives you the level of meta-ness. This is
> very subtle, which is probably not a good thing.
>
> Another approach would be to introduce a new dynamictype keyword that
> doesn’t need to be accessed as a member of self, and keep Self the way it
> is.  Self should work in structs as a type alias.
>
> Why don’t we turn this into a standard library function? It’s not something
> you need so often that the member access is very valuable. Putting it in
> the standard library as dynamicType(_:) does still allow for that function
> to be implemented using compiler magic.
>
> func dynamicType<T>(_: T) -> T.Type { }
>
> We have a proposal to remove .self on types. One reason .self exists is to
> avoid the mistake of writing let x = Int — the compiler will give you a
> weird type error later on in code if the value of x is what we today
> call Int.self but you meant to call the Int() initializer. Creating a
> metatype is not a common operation, so doing it explicitly is a good thing.
>
> It’s weird that you can use the metatype directly to construct something or
> to do member access, but you can’t access it as a bare value.
>
> Coming back to this proposal, if we removed .self why would we want to
> add .Self?
>
> If you have a variable whose value is a metatype, you also keep its name in
> lower case. So Self makes a little less sense from that aspect too.
>
> Another perspective is that .dynamicType is just an implicitly synthesized
> property on all type.
>
> We do have other keywords that follow the dot on
> types, Int.Type and Fooable.Protocol, so this isn’t the only thing. Those
> things are magic nested types.
>
> Subjectively, having dynamicType as a member feels weird.
>
> If .self goes away, the four-self example above is simplified,
> and .Self doesn’t make sense anymore. There’s also the difference
> that .Self would be a runtime thing.
>
>
>       What to do about optional requirements
>
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/14046
>
> People commonly ask why optional only works on Objective-C protocols, and
> the responses they get are usually that in Swift code you should reshape
> your protocols. As a starting assumption, we’re not making optionl work in
> Swift. So what do we do about this as part of the interoperability code?
>
> People do write these, but it’s often because they’re writing a delegate
> protocol and they’re following the example of Cocoa frameworks.
>
> Roughly three things we can do:
>
>  1. Rename it to make it clearly an Objective-C interop feature. We could
>     also forbid you actually spelling it in Swift code. That doesn’t work
>     well because it breaks your ability to write code in Swift that has
>     Objective-C clients — those clients won’t get the default
>     implementation from the extensions like you would use with Swift
>     clients instead of creating optional requirements.
>  2. Modeling optional requirements as a function of optional type such
>     as ((A, B) -> C)? doesn’t work well. For example, properties can have
>     optional type and they can be optional requirements, so you would end
>     up having to deal with a lot of extra complexity due to
>     double-optionals and likely want better code completion so you could
>     type it all out.
>  3. You force the default implementation to be visible from all callers,
>     and you do the dispatch at the call site. The only advantage of this is
>     that it takes optional requirements out of the language entirely. If
>     you wanted to implement the (somewhat common) pattern of checking
>     whether a type implements an optional requirement, you would have to
>     use a respondsToSelector check.
>
> The best pattern we’ve seen for checking conformance and using different
> code paths based on that is to use finer-grained protocols. (But there are
> still issues with organizing your code that way.)
>
> The caller default (#3) is really the only way to get optional requirements
> out of the type system. The weird code path in the compiler here is the
> same as the weird code path as we have in AnyObject. But it doesn’t look
> like we’re going to be able to do that.
>
> We can rename this as objcoptional or possibly demote it to an attribute.
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>