Re: [swift-evolution] Constant initialization and unreachable code.

[David Goodine via swift-evolution]

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 prefer to avoid it 
unless absolutely necessary.  Thanks for the 
head up on Active Compilation Conditions William, I wasn’t aware of it.  
Anything I can do to avoid the Build Settings tab is more than welcome.
-d


> On Oct 19, 2016, at 1:57 PM, William Sumner  wrote:
> 
> 
>> 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 switches (constant Bools) 
>> so that I can move back and forth between different features/implementations 
>> for testing, developing experimental features, migration, etc.  Currently if 
>> I write the following:
>> 
>> let useFoo = true
>> 
>> if useFoo {
>> // Foo code
>> } else {
>> // Non-Foo code
>> }
>> 
>> I will get compiler warnings either way that there’s unreachable code based 
>> on the value of useFoo.  That makes sense in most cases, but in some cases I 
>> need to leave the code as is for a while, and I hate leaving long-standing 
>> compiler warnings in production code.  (If it’s yellow, you need to pay 
>> attention to it.)  So I poked around and discovered that if I use the 
>> following declaration of useFoo, the warnings go away.
>> 
>> let useFoo = { return true }()
>> 
>> So, the question is, is this intentional? The compiler could certainly 
>> ascertain that useFoo will always be true and carry out the same dead code 
>> detection as for the first declaration.  If this isn’t intentional, and the 
>> compiler may at some point optimize away the closure and trigger dead code 
>> warnings, I might come up with a proposal that there is some idiom that 
>> allows one to do the above without the warnings.  I’m really not a fan of 
>> #define (because it’s just butt-ugly in such a beautiful language), but its 
>> existence is unavoidable for some cases.  
>> 
>> And, as I write this, I realized I haven’t tried declaring useFoo as var, 
>> but I expect that would trigger a warning that useFoo is not modified and 
>> should be defined by let.  I think this is a use case that, for practical 
>> purposes, should be covered to allow this type of evolution of code without 
>> generating warnings.  If the current behavior is intentional and going to 
>> stay, then that’s probably the best solution.
>> 
>> -d
> 
> You should use Active Compilation Conditions to create flags for conditional 
> compilation you can check with #if. If you’re not yet using Xcode 8, you can 
> manually define the flags under the Other Swift Flags build setting (e.g., 
> -DUSEFOO).
> 
> Preston

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Constant initialization and unreachable code.

[William Sumner via swift-evolution]

> 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 switches (constant Bools) 
> so that I can move back and forth between different features/implementations 
> for testing, developing experimental features, migration, etc.  Currently if 
> I write the following:
> 
> let useFoo = true
> 
> if useFoo {
> // Foo code
> } else {
> // Non-Foo code
> }
> 
> I will get compiler warnings either way that there’s unreachable code based 
> on the value of useFoo.  That makes sense in most cases, but in some cases I 
> need to leave the code as is for a while, and I hate leaving long-standing 
> compiler warnings in production code.  (If it’s yellow, you need to pay 
> attention to it.)  So I poked around and discovered that if I use the 
> following declaration of useFoo, the warnings go away.
> 
> let useFoo = { return true }()
> 
> So, the question is, is this intentional? The compiler could certainly 
> ascertain that useFoo will always be true and carry out the same dead code 
> detection as for the first declaration.  If this isn’t intentional, and the 
> compiler may at some point optimize away the closure and trigger dead code 
> warnings, I might come up with a proposal that there is some idiom that 
> allows one to do the above without the warnings.  I’m really not a fan of 
> #define (because it’s just butt-ugly in such a beautiful language), but its 
> existence is unavoidable for some cases.  
> 
> And, as I write this, I realized I haven’t tried declaring useFoo as var, but 
> I expect that would trigger a warning that useFoo is not modified and should 
> be defined by let.  I think this is a use case that, for practical purposes, 
> should be covered to allow this type of evolution of code without generating 
> warnings.  If the current behavior is intentional and going to stay, then 
> that’s probably the best solution.
> 
> -d

You should use Active Compilation Conditions to create flags for conditional 
compilation you can check with #if. If you’re not yet using Xcode 8, you can 
manually define the flags under the Other Swift Flags build setting (e.g., 
-DUSEFOO).

Preston___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Constant initialization and unreachable code.

[Alex Martini via swift-evolution]

> 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 
>> > 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 switches (constant Bools) 
>> so that I can move back and forth between different features/implementations 
>> for testing, developing experimental features, migration, etc.  Currently if 
>> I write the following:
>> 
>> let useFoo = true
>> 
>> if useFoo {
>> // Foo code
>> } else {
>> // Non-Foo code
>> }
> 
> In your debugging, do you actually need this condition to be evaluated at 
> runtime?  For example, in the debugger, are you changing the value of useFoo 
> at runtime to switch which branch is used?
> 
> If not, maybe #if would be better — it makes the decision at compile time.  I 
> don't get any warnings from the following code:
> 
> let useFoo = true
> 
> #if useFoo
> print("foo code")
> #else
> print("non-foo code")
> #endif

Sorry, I hit Send too soon.  That listing should read:

#if useFoo
print("foo code")
#else
print("non-foo code")
#endif

You switch useFoo on and off by passing "-D useFoo" to the compiler.  For 
example:

% swift test.swift
non-foo code

% swift -D useFoo test.swift
foo code

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Constant initialization and unreachable code.

[Alex Martini via swift-evolution]

> 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 switches (constant Bools) 
> so that I can move back and forth between different features/implementations 
> for testing, developing experimental features, migration, etc.  Currently if 
> I write the following:
> 
> let useFoo = true
> 
> if useFoo {
> // Foo code
> } else {
> // Non-Foo code
> }

In your debugging, do you actually need this condition to be evaluated at 
runtime?  For example, in the debugger, are you changing the value of useFoo at 
runtime to switch which branch is used?

If not, maybe #if would be better — it makes the decision at compile time.  I 
don't get any warnings from the following code:

let useFoo = true

#if useFoo
print("foo code")
#else
print("non-foo code")
#endif

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Constant initialization and unreachable code.

[Charlie Monroe via swift-evolution]

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 come to realize that this has a huge advantage of keeping all the 
debugging options together within the entire project and it eliminates any 
warnings.

> On Oct 19, 2016, at 1:50 PM, 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 switches (constant Bools) 
> so that I can move back and forth between different features/implementations 
> for testing, developing experimental features, migration, etc.  Currently if 
> I write the following:
> 
> let useFoo = true
> 
> if useFoo {
> // Foo code
> } else {
> // Non-Foo code
> }
> 
> I will get compiler warnings either way that there’s unreachable code based 
> on the value of useFoo.  That makes sense in most cases, but in some cases I 
> need to leave the code as is for a while, and I hate leaving long-standing 
> compiler warnings in production code.  (If it’s yellow, you need to pay 
> attention to it.)  So I poked around and discovered that if I use the 
> following declaration of useFoo, the warnings go away.
> 
> let useFoo = { return true }()
> 
> So, the question is, is this intentional? The compiler could certainly 
> ascertain that useFoo will always be true and carry out the same dead code 
> detection as for the first declaration.  If this isn’t intentional, and the 
> compiler may at some point optimize away the closure and trigger dead code 
> warnings, I might come up with a proposal that there is some idiom that 
> allows one to do the above without the warnings.  I’m really not a fan of 
> #define (because it’s just butt-ugly in such a beautiful language), but its 
> existence is unavoidable for some cases.  
> 
> And, as I write this, I realized I haven’t tried declaring useFoo as var, but 
> I expect that would trigger a warning that useFoo is not modified and should 
> be defined by let.  I think this is a use case that, for practical purposes, 
> should be covered to allow this type of evolution of code without generating 
> warnings.  If the current behavior is intentional and going to stay, then 
> that’s probably the best solution.
> 
> -d
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Constant initialization and unreachable code.

[David Goodine via swift-evolution]

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/implementations for 
testing, developing experimental features, migration, etc.  Currently if I 
write the following:

let useFoo = true

if useFoo {
// Foo code
} else {
// Non-Foo code
}

I will get compiler warnings either way that there’s unreachable code based on 
the value of useFoo.  That makes sense in most cases, but in some cases I need 
to leave the code as is for a while, and I hate leaving long-standing compiler 
warnings in production code.  (If it’s yellow, you need to pay attention to 
it.)  So I poked around and discovered that if I use the following declaration 
of useFoo, the warnings go away.

let useFoo = { return true }()

So, the question is, is this intentional? The compiler could certainly 
ascertain that useFoo will always be true and carry out the same dead code 
detection as for the first declaration.  If this isn’t intentional, and the 
compiler may at some point optimize away the closure and trigger dead code 
warnings, I might come up with a proposal that there is some idiom that allows 
one to do the above without the warnings.  I’m really not a fan of #define 
(because it’s just butt-ugly in such a beautiful language), but its existence 
is unavoidable for some cases.  

And, as I write this, I realized I haven’t tried declaring useFoo as var, but I 
expect that would trigger a warning that useFoo is not modified and should be 
defined by let.  I think this is a use case that, for practical purposes, 
should be covered to allow this type of evolution of code without generating 
warnings.  If the current behavior is intentional and going to stay, then 
that’s probably the best solution.

-d

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution