Hi Tony,
So if my understanding is correct, the basic proposal is the following:
func id<T>(t: T ?= T.defaultValue) { return t }
extension Int { static var defaultValue = 0 }
extension String { static var defaultValue = “” }
id() as Int // returns 0
id() as String // returns “”
id() as SomeRandomType // fails to type check — no default argument
I don’t understand what would happen if the caller is itself generic though,
for example:
callsID<T>(_ t: T) {
_ = id() as T
}
It appears that body of callsID() itself cannot type check without knowledge of
the concrete T that will be used with this function.
Slava
> On Nov 27, 2017, at 4:10 PM, Tony Allevato via swift-evolution
> <[email protected]> wrote:
>
> I totally agree that that's a good rule in general—I'm not 100% comfortable
> making an exception to it for this, but I wanted to start a discussion about
> a different approach than had been considered so far.
>
> The idea of forcing the user to acknowledge the explicitness of SFINAE with a
> strawman syntax `=?` instead of `=` was a thought experiment to bridge the
> wild-west-C++ world of templates and Swift's stricter generics, but I can
> definitely understand if even that kind of approach is something that the
> core team (who are far more familiar with the C++ side of that coin than I
> am) doesn't wish to support. As was pointed out, it's not something Swift
> supports anywhere else today.
>
> If we look at it from that point of view, where such a semantic treatment of
> generics would not be supported, I think it becomes a lot harder to
> rationalize treating this as "default arguments". What you really do have
> (and what writing it as constrained extensions makes clear) is additional
> overloads, because they only apply to certain subsets of types. If that's the
> case, maybe it's the wrong approach to try to turn overloads into "partial
> default values".
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution