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

I'd agree with that. Fortunately there are tools out there that can parse such things and generate the constants for us already. Waiting for Xcode to implement such common sense quality of life improvements probably won't end. I'll file bugs in the meantime though. Jon > On Jul 18, 2017, at

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

I think this should be a feature of Xcode to automatically generate / maintain these constants: When you add assets or create interface builder files, a plug-in could take care of generating / updating such constants and you would get auto-complete and type safety for free. > On Jul 18, 2017,

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

> Am 18.07.2017 um 00:58 schrieb Greg Parker via swift-users > : > > >> On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users >> wrote: >> >> Could / should these types be ExpressibleByStringLiteral? > > They should not. We are

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

> On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users > wrote: > > Could / should these types be ExpressibleByStringLiteral? They should not. We are deliberately discouraging the string literal of the name. The string literal should be in only one

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

Could / should these types be ExpressibleByStringLiteral? Nevin On Mon, Jul 17, 2017 at 12:47 PM, Manfred Schubert via swift-users < swift-users@swift.org> wrote: > > > Am 17.07.2017 um 18:08 schrieb Jon Shier : > > > > Making them an extension on String makes them visible

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

Making them an extension on String makes them visible everywhere String is used, unless you limit the visibility in some way, which impacts the performance of autocomplete and fills it with random constants. Like I said, part of the reason for this is to separate the constants. Jon

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

> On Jul 17, 2017, at 9:04 AM, Manfred Schubert wrote: > > >> Am 17.07.2017 um 17:47 schrieb Joe Groff : >> >> Yeah, this is the intended use pattern for these namespaced constant. You >> don't need the `rawValue:` label, though: >> >> extension

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

> On Jul 17, 2017, at 8:26 AM, Jon Shier via swift-users > wrote: > > 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

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

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 =

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

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: