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 
> <swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to