[swift-users] What is up with names not being Strings any more in Swift 4?

[Jon Shier]

	Like Notification.Name, I believe those types are supposed to help you namespace your string constants when you access them. I’d recommend using a code gen tool to generate them from your image assets, like:

extension NSImage.Name {
	static let customImage = NSImage.Name(rawValue: “customImage”)
}

Which can then be used like: NSImage(named: .customImage). That’s the ultimate use goal. It does make the old code awkward and a pain to migrate though.


Jon

> On Jul 17, 2017, at 11:20 AM, Manfred Schubert via swift-users <swift-users at swift.org> wrote:
> 
> Why are names no longer Strings any more in Swift 4? I am all for type safety, but now things like
> 
> NSImage(named: "Icon.png")
> 
> become
> 
> NSImage(named: NSImage.Name(rawValue: "Icon.png"))
> 
> and
> 
> NSWindowController(windowNibName: "Window")
> 
> becomes
> 
> NSWindowController(windowNibName: NSNib.Name(rawValue: "Window").
> 
> What does this contrived way of wrapping a String into something else gain in me in safety in exchange for this longer and more difficult to read code? For me a "name" is a prime example of a String. If a name isn't one, then nothing is.
> 
> One place where this makes a lot of sense to have is binding, and there is now NSBindingName. But how do I create a binding name for a property in a way that the compiler can check for validity? I only see the constructor from rawValue (String), but if I only create the binding name from a String I gain nothing in security.
> 
> 
> Kind regards,
> 
> Manfred
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users