> 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 place: the definition of th
There’s already a radar filed for this (I don’t know if there’s a JIRA bug
though).
The problem is that the standard library’s reflection mechanism only knows how
to map the in-memory representation of an enum to a case name for native Swift
enums. Objective-C enums are represented by their ‘ra
> On 17 Jul 2017, at 15:15, Michael Rogers via swift-users
> wrote:
>
> Hi, All:
>
> Can someone please enlighten me as to why the first enum works as expected,
> giving me Melbourne, but the second gives UIModalPresentationStyle rather
> than fullScreen?
Sure - it's because it's an alias th
Certain Objective-C enums don’t print a useful debug description. I
usually work around this by implementing CustomStringConvertible (or the debug
version) for the type myself. You probably want to file a bug with Apple.
Jon
> On Jul 17, 2017, at 6:15 PM, Michael Rogers via swift-user
Hi, All:
Can someone please enlighten me as to why the first enum works as expected,
giving me Melbourne, but the second gives UIModalPresentationStyle rather than
fullScreen?
enum City {
case Melbourne, Chelyabinsk, Bursa
}
let city = City.Bursa
print(city)
// prints "Melbourne"
let ci
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 everywhere String
> is
> Am 17.07.2017 um 18:12 schrieb Joe Groff :
>
> If you want to ensure that the string value corresponds to a declaration,
> maybe you could use #keyPath, which ought to be interchangeable with a string
> literal but checked by the compiler.
Excellent. Thanks a lot!
Manfred
_
> Am 17.07.2017 um 18:08 schrieb Jon Shier :
>
> 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.
I see. Thanks for clarifying.
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
>
> 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 NSImage.Name {
>> static let myImage = Name("m
> 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 NSImage.Name {
> static let myImage = Name("myImage")
> }
It would be possible to do the same thing as an extens
> 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 image assets, like:
>
>
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:
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(rawVal
TL;DR: I want to decode types differently based on whether they conform to a
protocol on top of "Decodable". I've figured out how to get keyed containers to
decode these types, but can't figure out how to do the same for un-keyed and
single value containers. Is it possible?
---
I have written s
Hi Itai
> • You’re getting a compiler error because of the difference between the
> representation of metatypes (Foo.Type for some type Foo) of concrete types
> (e.g. String, Int), and protocols (e.g. DefaultValueProvider). Some of the
> compiler folks can correct my exact use of terminol
16 matches
Mail list logo
