Re: [swift-evolution] Disallowing unreachable code

> On Mar 29, 2017, at 4:21 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 29, 2017, at 4:14 PM, Brent Royal-Gordon >> wrote: >> >>> On Mar 29, 2017, at 8:11 AM, John McCall via swift-evolution >>> wrote: >>> >>> I was suggesting that it would be a useful addition to the l

Re: [swift-evolution] Disallowing unreachable code

> On Mar 29, 2017, at 8:11 AM, John McCall via swift-evolution > wrote: > >> On Mar 29, 2017, at 9:15 AM, Alex Blewitt wrote: >>> On 29 Mar 2017, at 14:10, Jonathan Hull wrote: >>> >>> I think the idea is that it also adds a warning so you can find it later. >> >> @available(*, deprecated,

Re: [swift-evolution] Disallowing unreachable code

> On Mar 29, 2017, at 4:14 PM, Brent Royal-Gordon > wrote: > >> On Mar 29, 2017, at 8:11 AM, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I was suggesting that it would be a useful addition to the language, not >> that it >> necessarily needed new compile

Re: [swift-evolution] Disallowing unreachable code

> On Mar 29, 2017, at 8:11 AM, John McCall via swift-evolution > wrote: > > I was suggesting that it would be a useful addition to the language, not that > it > necessarily needed new compiler support. Personally, what I'd like to see is for the existing <#whatever#> placeholder syntax to be

Re: [swift-evolution] Disallowing unreachable code

> On Mar 24, 2017, at 3:54 PM, Peter Dillinger via swift-evolution > wrote: > > I don't see anything directly relevant to this in the archives, and I haven't > prepared a detailed proposal. But I'm raising the general idea because I > recently criticized Swift 3 for allowing unreachable code

Re: [swift-evolution] Disallowing unreachable code

> On Mar 29, 2017, at 12:55 AM, Peter Dillinger > wrote: >>> On Mar 28, 2017, at 9:40 PM, Peter Dillinger >>> wrote: Agreed, we have the right design here. The go community has shown the result of taking a hard line on this, and it really hurts refactoring and other exper

Re: [swift-evolution] Disallowing unreachable code

> On Mar 29, 2017, at 9:15 AM, Alex Blewitt wrote: >> On 29 Mar 2017, at 14:10, Jonathan Hull > > wrote: >> >> I think the idea is that it also adds a warning so you can find it later. > > @available(*, deprecated, message: "Don't forget to implement this") > func unimplem

Re: [swift-evolution] Disallowing unreachable code

> On 29 Mar 2017, at 14:10, Jonathan Hull wrote: > > I think the idea is that it also adds a warning so you can find it later. @available(*, deprecated, message: "Don't forget to implement this") func unimplemented(_ file:String = #file,_ line:Int = #line) -> T { fatalError("Not implemented \

Re: [swift-evolution] Disallowing unreachable code

I think the idea is that it also adds a warning so you can find it later. > On Mar 29, 2017, at 6:06 AM, Alex Blewitt wrote: > > On 29 Mar 2017, at 11:38, Jonathan Hull via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Mar 27, 2017, at 11:27 AM, John McCall via swi

Re: [swift-evolution] Disallowing unreachable code

On 29 Mar 2017, at 11:38, Jonathan Hull via swift-evolution wrote: > > >> On Mar 27, 2017, at 11:27 AM, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> In fact, we should probably double-down on this design and add an >> "unimplemented" expression that alwa

Re: [swift-evolution] Disallowing unreachable code

> On Mar 27, 2017, at 11:27 AM, John McCall via swift-evolution > wrote: > > In fact, we should probably double-down on this design and add an > "unimplemented" expression that always triggers warnings and just traps if > you try to evaluate it. That expression would be a logical thing to use

Re: [swift-evolution] Disallowing unreachable code

> On 24 Mar 2017, at 22:54, Peter Dillinger via swift-evolution > wrote: > > I don't see anything directly relevant to this in the archives, and I haven't > prepared a detailed proposal. But I'm raising the general idea because I > recently criticized Swift 3 for allowing unreachable code in

Re: [swift-evolution] Disallowing unreachable code

> On Mar 28, 2017, at 9:55 PM, Peter Dillinger via swift-evolution > wrote: > >>> Missing 'try' is a fatal issue? >> >> That could be argued I suppose, I was referring to unreachable code, unused >> variables, >> variables that are never mutated, etc. > > And what about non-exhaustive switch?

Re: [swift-evolution] Disallowing unreachable code

On Mar 28, 2017, at 21:55, Peter Dillinger via swift-evolution wrote: On Mar 28, 2017, at 9:40 PM, Peter Dillinger wrote: Agreed, we have the right design here. The go community has shown the result of taking a hard line on this, and it really hurts refactoring and

Re: [swift-evolution] Disallowing unreachable code

>> On Mar 28, 2017, at 9:40 PM, Peter Dillinger >> wrote: >>> Agreed, we have the right design here. The go community has shown the >>> result of taking >>> a hard line on this, and it really hurts refactoring and other experimental >>> “pound out some >>> code” prototyping use cases. We use

Re: [swift-evolution] Disallowing unreachable code

> On Mar 28, 2017, at 9:40 PM, Peter Dillinger > wrote: > >> Agreed, we have the right design here. The go community has shown the >> result of taking >> a hard line on this, and it really hurts refactoring and other experimental >> “pound out some >> code” prototyping use cases. We use war

Re: [swift-evolution] Disallowing unreachable code

> Agreed, we have the right design here. The go community has shown the result > of taking > a hard line on this, and it really hurts refactoring and other experimental > “pound out some > code” prototyping use cases. We use warnings for things that “should be > cleaned up before > code is com

Re: [swift-evolution] Disallowing unreachable code

> On Mar 27, 2017, at 10:25 AM, John McCall via swift-evolution > wrote: > >> On Mar 24, 2017, at 6:54 PM, Peter Dillinger via swift-evolution >> wrote: >> I don't see anything directly relevant to this in the archives, and I >> haven't prepared a detailed proposal. But I'm raising the gene

Re: [swift-evolution] Disallowing unreachable code

> On Mar 27, 2017, at 11:27 AM, Peter Dillinger via swift-evolution > wrote: > >> -1, for all the reasons others have already explained. This unnecessarily >> complicates the debugging process. If you ship code with warnings still in >> it, that’s your own fault. > > All the obsolete/unfound

Re: [swift-evolution] Disallowing unreachable code

> On Mar 27, 2017, at 1:48 PM, Peter Dillinger > wrote: > >> To use a germane example, if unreachable code were always an error, a >> programmer trying to >> debug a problem wouldn't be able to short-circuit a function by just adding >> a return; > > True, but > >> they'd also have to commen

Re: [swift-evolution] Disallowing unreachable code

> -1, for all the reasons others have already explained. This unnecessarily > complicates the debugging process. If you ship code with warnings still in > it, that’s your own fault. All the obsolete/unfounded reasons? Please address my technical arguments directly, rather than in the (potentia

Re: [swift-evolution] Disallowing unreachable code

> On Mar 24, 2017, at 5:54 PM, Peter Dillinger via swift-evolution > wrote: > > I don't see anything directly relevant to this in the archives, and I haven't > prepared a detailed proposal. But I'm raising the general idea because I > recently criticized Swift 3 for allowing unreachable code

Re: [swift-evolution] Disallowing unreachable code

> To use a germane example, if unreachable code were always an error, a > programmer trying to > debug a problem wouldn't be able to short-circuit a function by just adding a > return; True, but > they'd also have to comment out the rest of the function. No, as you can do if (true) { re

Re: [swift-evolution] Disallowing unreachable code

I should have clarified what I mean by "unreachable". I am referring to user code that is orphaned in a standard control flow graph construction, which does not perform any optimizations based on the values of expressions. The following has unreachable code: return 42; return -1; // unrea

Re: [swift-evolution] Disallowing unreachable code

This is more of a developer practice that a team implements than an actual Swift/Xcode language feature. Also, I believe (not 100% sure) this wouldn't work for functions/properties that are dynamically dispatched. The compiler wouldn't know if the function will be called until runtime. On Mon, Mar

Re: [swift-evolution] Disallowing unreachable code

> On Mar 27, 2017, at 12:25 PM, John McCall via swift-evolution > wrote: > >> On Mar 24, 2017, at 6:54 PM, Peter Dillinger via swift-evolution >> wrote: >> I don't see anything directly relevant to this in the archives, and I >> haven't prepared a detailed proposal. But I'm raising the gene

Re: [swift-evolution] Disallowing unreachable code

> On Mar 24, 2017, at 6:54 PM, Peter Dillinger via swift-evolution > wrote: > I don't see anything directly relevant to this in the archives, and I haven't > prepared a detailed proposal. But I'm raising the general idea because I > recently criticized Swift 3 for allowing unreachable code in

Re: [swift-evolution] Disallowing unreachable code

I'm personally -1 on this. I find it useful from time to time when debugging certain features - instead of commenting some part of code (and potentially forgetting to uncomment it), I wrap it in an "if false" statement - while I get a warning about the code not being reachable (or the if state

[swift-evolution] Disallowing unreachable code

I don't see anything directly relevant to this in the archives, and I haven't prepared a detailed proposal. But I'm raising the general idea because I recently criticized Swift 3 for allowing unreachable code in a blog post: https://blogs.synopsys.com/software-integrity/2017/03/24/swift-program