Re: [swift-evolution] Disallowing unreachable code

[Joe Groff via swift-evolution]

> 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 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 treated as an unimplemented() call. That probably 
>> *would* require compiler support, although fortunately we already parse this 
>> syntax into an EditorPlaceholderExpr.
> 
> Actually, looking more closely, we already have this behavior in playgrounds 
> (and REPLs); it's only an error when you compile. Like, we literally do this:
> 
>   // Found it. Flag it as error (or warning, if in playground mode) for 
> the
>   // rest of the compiler pipeline and lex it as an identifier.
>   if (LangOpts.Playground) {
> diagnose(TokStart, diag::lex_editor_placeholder_in_playground);
>   } else {
> diagnose(TokStart, diag::lex_editor_placeholder);
>   }
> 
> Could we change the compile-time error into a warning? Would that require an 
> evolution proposal?

Ah, you beat me to it. I would support reducing this to a warning.

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

Re: [swift-evolution] Disallowing unreachable code

[Joe Groff via swift-evolution]

> 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, message: "Don't forget to implement this")
>> func unimplemented(_ file:String = #file,_ line:Int = #line) -> T {
>>   fatalError("Not implemented \(file):\(line)")
>> }
>> 
>> let f: String = unimplemented()
> 
> I was suggesting that it would be a useful addition to the language, not that 
> it
> necessarily needed new compiler support.
> 
> Does someone want to write a proposal for it?

Placeholder expressions in fact have this exact behavior in "playgrounds mode" 
already. We could easily make it so that placeholders warn rather than error in 
normal source code as well.

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

Re: [swift-evolution] Disallowing unreachable code

[Brent Royal-Gordon via swift-evolution]

> 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 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 treated as an unimplemented() call. That probably *would* 
> require compiler support, although fortunately we already parse this syntax 
> into an EditorPlaceholderExpr.

Actually, looking more closely, we already have this behavior in playgrounds 
(and REPLs); it's only an error when you compile. Like, we literally do this:

  // Found it. Flag it as error (or warning, if in playground mode) for the
  // rest of the compiler pipeline and lex it as an identifier.
  if (LangOpts.Playground) {
diagnose(TokStart, diag::lex_editor_placeholder_in_playground);
  } else {
diagnose(TokStart, diag::lex_editor_placeholder);
  }

Could we change the compile-time error into a warning? Would that require an 
evolution proposal?

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Disallowing unreachable code

[Brent Royal-Gordon via swift-evolution]

> 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 treated as an unimplemented() call. That probably *would* require 
compiler support, although fortunately we already parse this syntax into an 
EditorPlaceholderExpr.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Disallowing unreachable code

[Joe Groff via swift-evolution]

> 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 in a blog post: 
> https://blogs.synopsys.com/software-integrity/2017/03/24/swift-programming-language-design-part-2/
>  (search for "unreachable code").  And I want you to have every opportunity 
> to rectify this, even though I'm in the business of finding defects the 
> compiler doesn't.  :)
> 
> Part of my argument is that people commonly ignore compiler warnings.  We see 
> lots of defective code that would be (or is) caught by compiler warnings but 
> people don't pay attention.

That's a fair concern, but unlike C compilers, where warnings vary widely among 
implementations and often aren't even on by default, Swift's warnings are 
considered as part of the language design and can't be turned off, so there's 
less opportunity or excuse to ignore them.

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

Re: [swift-evolution] Disallowing unreachable code

[John McCall via swift-evolution]

> 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 
 experimental “pound out some
 code” prototyping use cases.  We use warnings for things that “should be 
 cleaned up before
 code is committed”, but which is not itself a fatal issue.
>>> 
>>> 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?
> 
> Both of these existing rules seem to violate the principle claimed, because 
> they are hazards to incomplete or experimental changes that might lead people 
> to use quick fixes (try!; default) that are not associated with a warning, 
> whereas a warning instead of the error would (as you claim) signal to the 
> user there are pending fixes before commit.
> 
> In theory, your position seems defensible, but I'm not seeing consistency in 
> application.

Non-exhaustive switch is like a missing return statement: the code isn't just 
"suspicious", it's potentially unsound if the warning is correct.  That's not 
true of unreachable code or ignored return values.  We could, of course, invent 
semantics for it, like implicitly asserting or implicitly falling through; but 
the former is inconsistent with our safety goals, and the second is likely to 
just lead to worse downstream diagnostics.

You're correct that enforcing "try" as a hard error is not consistent with 
being lax about experimental code, but the entire point of "try" is to reliably 
mark places that can throw; making it only a warning would completely undermine 
that.  If we had a language mode focused on experimental code, then yes, it 
would be appropriate to disable the "try" diagnostic; but adding a language 
mode like that would be really destructive long-term, outside of specific 
situations like coding in the debugger.

I would say that the "incomplete" side of the coin is more important to us than 
the "experimental" side.  We don't want laxer rules for experimental code 
because in practice there's usually no bright line between prototypes and 
production.  But if our hand isn't being forced, and we don't have strong 
language-design reasons to enforce the rule, a warning is fine.

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

Re: [swift-evolution] Disallowing unreachable code

[John McCall via swift-evolution]

> 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 unimplemented(_ file:String = #file,_ line:Int = #line) -> T {
>   fatalError("Not implemented \(file):\(line)")
> }
> 
> let f: String = unimplemented()

I was suggesting that it would be a useful addition to the language, not that it
necessarily needed new compiler support.

Does someone want to write a proposal for it?

John.

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

Re: [swift-evolution] Disallowing unreachable code

[Alex Blewitt via swift-evolution]

> 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 \(file):\(line)")
}

let f: String = unimplemented()

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

Re: [swift-evolution] Disallowing unreachable code

[Jonathan Hull via swift-evolution]

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 
> > wrote:
>> 
>> 
>>> 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 in 
>>> e.g. code snippets automatically inserted by an IDE.
>> 
>> Yes, please.
> 
> 
> You can do this already:
> 
> func unimplemented(_ file:String = #file,_ line:Int = #line) -> T {
>   fatalError("Not implemented \(file):\(line)")
> }
> 
> let f: String = unimplemented()
> 
> 

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

Re: [swift-evolution] Disallowing unreachable code

[Alex Blewitt via swift-evolution]

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 
>> > 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 in 
>> e.g. code snippets automatically inserted by an IDE.
> 
> Yes, please.


You can do this already:

func unimplemented(_ file:String = #file,_ line:Int = #line) -> T {
  fatalError("Not implemented \(file):\(line)")
}

let f: String = unimplemented()


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

Re: [swift-evolution] Disallowing unreachable code

[Jonathan Hull via swift-evolution]

> 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 in 
> e.g. code snippets automatically inserted by an IDE.

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

Re: [swift-evolution] Disallowing unreachable code

[Haravikk via swift-evolution]

> 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 a blog post: 
> https://blogs.synopsys.com/software-integrity/2017/03/24/swift-programming-language-design-part-2/
>  (search for "unreachable code").  And I want you to have every opportunity 
> to rectify this, even though I'm in the business of finding defects the 
> compiler doesn't.  :)
> 
> Part of my argument is that people commonly ignore compiler warnings.  We see 
> lots of defective code that would be (or is) caught by compiler warnings but 
> people don't pay attention.

Which people? Personally warnings bug me no end; I'm not happy until they're 
all dealt with, so a warning is more than sufficient in my case.

While obviously writing unreachable code on purpose isn't the best way to do 
something, sometimes throwing some code into an if (false) or dropping in an 
early return to see if it fixes or triggers a problem is a perfectly reasonable 
way to do something in a quick and dirty way.

IMO a warning is more than sufficient for this, so that the programmer is 
reminded to go back and fix it.

I don't know if it's possible to elevate specific warnings to errors (I used to 
do this working with Java in Eclipse but have never wanted to in Xcode), if not 
then that may be worth considering as an alternative? But as a default I think 
a warning is sufficient, at least for me, as I'd rather be able to make code 
unreachable than have an error when it is.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Disallowing unreachable code

[Brent Royal-Gordon via swift-evolution]

> 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?
> 
> Both of these existing rules seem to violate the principle claimed, because 
> they are hazards to incomplete or experimental changes that might lead people 
> to use quick fixes (try!; default) that are not associated with a warning, 
> whereas a warning instead of the error would (as you claim) signal to the 
> user there are pending fixes before commit.

Here's a different principle: When Swift generates a warning, the mistake has 
no runtime effect on the behavior of the code, but things like non-exhaustive 
`switch` or a missing `try` represent code where you haven't told the compiler 
how to handle some of the circumstances it might encounter.

If you stick a `return` in the middle of some code, the compiler knows exactly 
how to interpret that: Return there and don't run the code after it. If you 
write a non-exhaustive `switch`, what is the compiler supposed to do? Fall out 
of `switch` statement? Trap? It's unclear. Similarly, if there's no 
`try`—particularly outside of a `do`/`catch` block or `throws` function—what 
behavior should the compiler assume you want?

Trapping is clearly the proper choice, because Swift's philosophy is to trap 
whenever the program finds itself in a state that the programmer did not 
anticipate. And yet you don't want the *lack* of something to cause a trap; you 
should at least be able to see the operation so you have a chance to recognize 
the potential to trap. (Implicitly unwrapped optionals are the exception that 
proves the rule--many programmers ban them because they cause invisible 
trapping. You don't want people banning `switch` or `throw` statements because 
of their invisible danger.) Any other option, though, runs the risk of letting 
a program run off the rails and do the wrong thing.

So we emit an error in these cases because the programmer has written ambiguous 
code, and the compiler has no good option for resolving the ambiguity. On the 
other hand, if you use `var` instead of `let`, or write code after a `return`, 
the instructions your code is giving the compiler are unambiguous; they're just 
not phrased as well as they could be. So we emit a program that does what your 
code says and politely point out that you could write it better.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Disallowing unreachable code

[David Sweeris via swift-evolution]

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 other 
 experimental “pound out some
 code” prototyping use cases.  We use warnings for things that “should be 
 cleaned up before
 code is committed”, but which is not itself a fatal issue.
>>> 
>>> 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?

Switches are required to be exhaustive in Swift, but code is not required to be 
called.

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

Re: [swift-evolution] Disallowing unreachable code

[Peter Dillinger via swift-evolution]

>> 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 warnings for things that “should be 
>>> cleaned up before
>>> code is committed”, but which is not itself a fatal issue.
>> 
>> 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?

Both of these existing rules seem to violate the principle claimed, because 
they are hazards to incomplete or experimental changes that might lead people 
to use quick fixes (try!; default) that are not associated with a warning, 
whereas a warning instead of the error would (as you claim) signal to the user 
there are pending fixes before commit.

In theory, your position seems defensible, but I'm not seeing consistency in 
application.

-peter

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

Re: [swift-evolution] Disallowing unreachable code

[Chris Lattner via swift-evolution]

> 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 warnings for things that “should be 
>> cleaned up before
>> code is committed”, but which is not itself a fatal issue.
> 
> 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.

-Chris

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

Re: [swift-evolution] Disallowing unreachable code

[Peter Dillinger via swift-evolution]

> 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 committed”, but which is not itself a fatal issue.

Missing 'try' is a fatal issue?

-- 
Peter Dillinger, Ph.D.
Software Engineering Manager, Coverity Analysis, Software Integrity Group | 
Synopsys
www.synopsys.com/software


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

Re: [swift-evolution] Disallowing unreachable code

[Chris Lattner via swift-evolution]

> 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 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-programming-language-design-part-2/
>>  (search for "unreachable code").  And I want you to have every opportunity 
>> to rectify this, even though I'm in the business of finding defects the 
>> compiler doesn't.  :)
>> 
>> Part of my argument is that people commonly ignore compiler warnings.  We 
>> see lots of defective code that would be (or is) caught by compiler warnings 
>> but people don't pay attention.
> 
> It was, indeed, something of a policy goal for awhile to not have any 
> compiler warnings in Swift.  The idea was that anything suspect should be an 
> error.  We deliberately backed away from that because it was actually really 
> disruptive to the development experience: even very conscientious programmers 
> who diligently fix all their warnings sometimes have code "in flight", so to 
> speak, and want to be able to test and debug it without immediately making 
> invasive edits.  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; they'd also have to comment 
> out the rest of the function.
> 
> I think we're comfortable with the current balance.  It's understood that 
> some programmers just ignore compiler warnings, but there are costs on the 
> other side, too.

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 committed”, but which is not 
itself a fatal issue.

-Chris


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

Re: [swift-evolution] Disallowing unreachable code

[David Sweeris via swift-evolution]

> 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/unfounded reasons?  Please address my technical arguments 
> directly, rather than in the (potentially stale/unfounded) abstract.

-1, because having to write out “if(true) {…}” just because somebody might 
ignore a warning is annoying.

I wouldn’t object to the “—treatWarningsAsErrors” flag someone else mentioned.

- Dave Sweeris

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

Re: [swift-evolution] Disallowing unreachable code

[John McCall via swift-evolution]

> 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 comment out the rest of the function.
> 
> No, as you can do
> 
>  if (true) {
>return -1
>  }
> 
> See clarifying reply on definition of "unreachable".

I'm not claiming that it's impossible to suppress the error.  I'm saying that 
we made a conscious decision to not use hard errors for issues that merely 
*might* indicate a semantic mistake because doing so can interfere with the 
realities of development.

Note that such interference can be actively counter-productive.  If a 
diagnostic is a warning, the programmer can safely put it out of mind because 
the warning will stick around until they fix it.  If the diagnostic is instead 
an error, they'll have to immediately suppress it in order to get on with the 
build; that suppression mechanism will remain in place indefinitely until they 
come back and fix it.

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 in e.g. 
code snippets automatically inserted by an IDE.

John.

> Returning to Charlie's reply:
>> Similarly returning earlier. The warning is convenient as it warns you to 
>> review that part
>> before releasing the code to the public.
> 
> Since swift implements a warning for the if(true) or if(false) cases, we 
> still get that, and without the cost of accepting code with a serious chance 
> of being accidentally wrong.  I don't think anyone ever wrote if(true) or 
> if(false) expecting some behavior other than what they wrote.
> 
> -- 
> Peter Dillinger, Ph.D.
> Software Engineering Manager, Coverity Analysis, Software Integrity Group | 
> Synopsys
> www.synopsys.com/software
> 

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

Re: [swift-evolution] Disallowing unreachable code

[Peter Dillinger via swift-evolution]

> -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 (potentially stale/unfounded) abstract.

-- 
Peter Dillinger, Ph.D.
Software Engineering Manager, Coverity Analysis, Software Integrity Group | 
Synopsys
www.synopsys.com/software


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

Re: [swift-evolution] Disallowing unreachable code

[Charles Srstka via swift-evolution]

> 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 in a blog post: 
> https://blogs.synopsys.com/software-integrity/2017/03/24/swift-programming-language-design-part-2/
>  (search for "unreachable code").  And I want you to have every opportunity 
> to rectify this, even though I'm in the business of finding defects the 
> compiler doesn't.  :)
> 
> Part of my argument is that people commonly ignore compiler warnings.  We see 
> lots of defective code that would be (or is) caught by compiler warnings but 
> people don't pay attention.
> 
> If you would like to see more defect examples from open-source software 
> (other languages for the moment), I am able to dig up such things.
> 
> Thanks
> 
> --
> Peter Dillinger, Ph.D.
> Software Engineering Manager, Coverity Analysis, Software Integrity Group | 
> Synopsys
> www.synopsys.com/software
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-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.

Charles

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

Re: [swift-evolution] Disallowing unreachable code

[Peter Dillinger via swift-evolution]

> 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) {
return -1
  }

See clarifying reply on definition of "unreachable".

Returning to Charlie's reply:
> Similarly returning earlier. The warning is convenient as it warns you to 
> review that part
> before releasing the code to the public.

Since swift implements a warning for the if(true) or if(false) cases, we still 
get that, and without the cost of accepting code with a serious chance of being 
accidentally wrong.  I don't think anyone ever wrote if(true) or if(false) 
expecting some behavior other than what they wrote.

-- 
Peter Dillinger, Ph.D.
Software Engineering Manager, Coverity Analysis, Software Integrity Group | 
Synopsys
www.synopsys.com/software

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

Re: [swift-evolution] Disallowing unreachable code

[Peter Dillinger via swift-evolution]

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; // unreachable

The following does not (from the blog post: "use 'if (false)' all you want"):

  if (false) {
return -1;
  }

And the following, which allows you to bypass an existing function definition 
does not:

  if (true) {
return -1;
  }

We call that "dead code" and in particular "intentional" because it's obvious 
from how it's written that the programmer intended to disable some code.  The 
reason for disallowing unreachable code is that it's too easy get accidentally, 
which also makes the intent unclear.


-- 
Peter Dillinger, Ph.D.
Software Engineering Manager, Coverity Analysis, Software Integrity Group | 
Synopsys
www.synopsys.com/software
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Disallowing unreachable code

[Matthew Johnson via swift-evolution]

> 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 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-programming-language-design-part-2/
>>  (search for "unreachable code").  And I want you to have every opportunity 
>> to rectify this, even though I'm in the business of finding defects the 
>> compiler doesn't.  :)
>> 
>> Part of my argument is that people commonly ignore compiler warnings.  We 
>> see lots of defective code that would be (or is) caught by compiler warnings 
>> but people don't pay attention.
> 
> It was, indeed, something of a policy goal for awhile to not have any 
> compiler warnings in Swift.  The idea was that anything suspect should be an 
> error.  We deliberately backed away from that because it was actually really 
> disruptive to the development experience: even very conscientious programmers 
> who diligently fix all their warnings sometimes have code "in flight", so to 
> speak, and want to be able to test and debug it without immediately making 
> invasive edits.  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; they'd also have to comment 
> out the rest of the function.
> 
> I think we're comfortable with the current balance.  It's understood that 
> some programmers just ignore compiler warnings, but there are costs on the 
> other side, too.

+1.  I like this being a warning for exactly the reasons you state.  It’s very 
useful to sometimes be able to just insert an early return when debugging.

> 
> John.
> 
>> 
>> If you would like to see more defect examples from open-source software 
>> (other languages for the moment), I am able to dig up such things.
>> 
>> Thanks
>> 
>> --
>> Peter Dillinger, Ph.D.
>> Software Engineering Manager, Coverity Analysis, Software Integrity Group | 
>> Synopsys
>> www.synopsys.com/software
>> 
>> ___
>> 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Disallowing unreachable code

[John McCall via swift-evolution]

> 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 a blog post: 
> https://blogs.synopsys.com/software-integrity/2017/03/24/swift-programming-language-design-part-2/
>  (search for "unreachable code").  And I want you to have every opportunity 
> to rectify this, even though I'm in the business of finding defects the 
> compiler doesn't.  :)
> 
> Part of my argument is that people commonly ignore compiler warnings.  We see 
> lots of defective code that would be (or is) caught by compiler warnings but 
> people don't pay attention.

It was, indeed, something of a policy goal for awhile to not have any compiler 
warnings in Swift.  The idea was that anything suspect should be an error.  We 
deliberately backed away from that because it was actually really disruptive to 
the development experience: even very conscientious programmers who diligently 
fix all their warnings sometimes have code "in flight", so to speak, and want 
to be able to test and debug it without immediately making invasive edits.  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; they'd also have to comment out the rest of the function.

I think we're comfortable with the current balance.  It's understood that some 
programmers just ignore compiler warnings, but there are costs on the other 
side, too.

John.

> 
> If you would like to see more defect examples from open-source software 
> (other languages for the moment), I am able to dig up such things.
> 
> Thanks
> 
> --
> Peter Dillinger, Ph.D.
> Software Engineering Manager, Coverity Analysis, Software Integrity Group | 
> Synopsys
> www.synopsys.com/software
> 
> ___
> 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

Re: [swift-evolution] Disallowing unreachable code

[Charlie Monroe via swift-evolution]

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 statement always evaluating to false), I can test 
your code and then go by the warnings and remove the "if false" statements.

Similarly returning earlier. The warning is convenient as it warns you to 
review that part before releasing the code to the public.

If we take into account the argument that people commonly ignore compiler 
warnings, we should enable "treat warnings as errors" by default - which I'm 
sure is not the correct way to go.


> On Mar 24, 2017, at 11: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 a blog post: 
> https://blogs.synopsys.com/software-integrity/2017/03/24/swift-programming-language-design-part-2/
>  (search for "unreachable code").  And I want you to have every opportunity 
> to rectify this, even though I'm in the business of finding defects the 
> compiler doesn't.  :)
> 
> Part of my argument is that people commonly ignore compiler warnings.  We see 
> lots of defective code that would be (or is) caught by compiler warnings but 
> people don't pay attention.
> 
> If you would like to see more defect examples from open-source software 
> (other languages for the moment), I am able to dig up such things.
> 
> Thanks
> 
> --
> Peter Dillinger, Ph.D.
> Software Engineering Manager, Coverity Analysis, Software Integrity Group | 
> Synopsys
> www.synopsys.com/software
> 
> ___
> 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