William and Alex, thanks for the reply. I’m aware of the compile-time option.
My post was originally to ask if the difference between constant and closure
initialization for constants was intentional (and likely to remain) or just a
temporary idiosyncrasy. I find #ifdef to be ugly and like pr
> On Oct 19, 2016, at 5:50 AM, David Goodine via swift-evolution
> wrote:
>
> Hey all,
>
> I don’t know if this is really an ‘evolution’ topic per se, and I’m not on
> Swift Dev, but thought someone here could shed some light on this.
>
> Often when developing code, if I need create mode swi
> On Oct 19, 2016, at 9:37 AM, Alex Martini via swift-evolution
> wrote:
>
>>
>> On Oct 19, 2016, at 4:50 AM, David Goodine via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> Hey all,
>>
>> I don’t know if this is really an ‘evolution’ topic per se, and I’m not on
>> Sw
> On Oct 19, 2016, at 4:50 AM, David Goodine via swift-evolution
> wrote:
>
> Hey all,
>
> I don’t know if this is really an ‘evolution’ topic per se, and I’m not on
> Swift Dev, but thought someone here could shed some light on this.
>
> Often when developing code, if I need create mode swi
That’s an interesting approach. My cases tend to be more localized (the let is
right before the if), but I can see how the struct approach would be better if
the code switching were expected to be more long term, or even permanent. It
still raises the original question whether this is intende
Hi David,
I find these warning useful at times, annoying at others - like in your case.
I've personally come to a solution where I've declared a struct that contains
these values:
struct Debug {
static let useFoo = true
}
if Debug.useFoo {
print("yes")
} else {
print("no")
}
I've
Hey all,
I don’t know if this is really an ‘evolution’ topic per se, and I’m not on
Swift Dev, but thought someone here could shed some light on this.
Often when developing code, if I need create mode switches (constant Bools) so
that I can move back and forth between different features/impleme
