[swift-evolution] [swift-users] Very unexpected automatic behaviour between StringLiteralConvertible and pattern matching!

David Hart david at hartbit.com
Wed Jan 6 16:31:35 CST 2016


I can file those bugs. Would it be beneficial if I also created failing unit tests?
David.

> On 06 Jan 2016, at 20:05, Joe Groff <jgroff at apple.com> wrote:
> 
>> 
>> On Jan 5, 2016, at 9:28 AM, David Hart via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>> 
>> How is it that Swift allows code like this:
>> 
>> struct Sneaky: StringLiteralConvertible {
>> 	init(stringLiteral value: String) {}
>> 	init(extendedGraphemeClusterLiteral value: String) {}
>> 	init(unicodeScalarLiteral value: String) {}
>> }
>> 
>> func ~=(sneaky: Sneaky, string: String) -> Bool {
>> 	return false
>> }
>> 
>> enum NormalEnum: String {
>> 	case Super = "super"
>> 	case Mario = "mario"
>> }
>> 
>> let value = NormalEnum(rawValue: "super”) // return nil!!!!
> 
> I see two bugs here. When an enum has a raw value type, the compiler generates this initializer:
> 
> init(rawValue: String) {
>   switch rawValue {
>   case "super":
>     self = .Super
>   ...
>   }
> }
> 
> so uses ~= pattern matching to match the raw value. It would be more sensible to always use `==` comparison in the synthesized initializer. However, I'm surprised too that the type checker favors ~=(Sneaky, String) over ~=(String, String); it should at best be ambiguous. Do you have time to file these two bugs?
> 
> -Joe
> 
>> 
>> It hit completely by surprise today because of of a Regex library:
>> 
>> struct Regex: StringLiteralConvertible {
>> 	init(stringLiteral value: String) {}
>> 	init(extendedGraphemeClusterLiteral value: String) {}
>> 	init(unicodeScalarLiteral value: String) {}
>> 
>> 	//...
>> }
>> 
>> func ~=(regex: Regex, string: String) -> Bool {
>> 	return regex.matches(string)
>> }
>> 
>> If I was not already a Swift enthusiast, this behaviour would have left me completely dumbfounded.
>> What can we do about it?
>> 
>> David.
>> 
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org <mailto:swift-users at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users <https://lists.swift.org/mailman/listinfo/swift-users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160106/4b6ecf71/attachment.html>


More information about the swift-evolution mailing list