[Pitch] #error

[CTMacUser (Daryle Walker)]

Unconditional Error Messages
Proposal: SE-NNNN <file:///Users/daryle/NNNN-filename.md>
Authors: Daryle Walker <https://github.com/CTMacUser&gt;, Author 2 <https://github.com/swiftdev&gt;
Review Manager: TBD
Status: Awaiting review
During the review process, add the following fields as needed:

Decision Notes: Rationale <https://lists.swift.org/pipermail/swift-evolution/&gt;, Additional Commentary <https://lists.swift.org/pipermail/swift-evolution/&gt;
Bugs: SR-NNNN <Issues · apple/swift-issues · GitHub, SR-MMMM <Issues · apple/swift-issues · GitHub;
Previous Revision: 1 <https://github.com/apple/swift-evolution/blob/...commit-ID.../proposals/NNNN-filename.md&gt;
Previous Proposal: SE-XXXX <file:///Users/daryle/XXXX-filename.md>
Introduction
This proposal adds the #error directive, which unconditionally posts a compile-time error.

Swift-evolution thread: Discussion thread topic for that proposal <https://lists.swift.org/pipermail/swift-evolution/&gt;
Motivation
A conditional compilation block permits branches of code based on the compilation conditions.

#if compilation condition 1
// statements to compile if compilation condition 1 is true
#elseif compilation condition 2
// statements to compile if compilation condition 2 is true
#else
// statements to compile if both compilation conditions are false
#endif
A block lets at most one of its branches to be incorporated into the compiled module. But compilation always occurs; there is no scenario to flag conditions that should never allow compiling.

When suspending work on a source file for a while, marking where you ended work with an unconditional error message would let the compiler remind you where you left off.

Proposed solution
The solution is to add a new compiler control statement, one that posts a fatal diagnostic during compilation. It can include a message to aid the user on how to change their code.

It's called #error, after the C preprocessor directive that has the same effects.

For example, instead of checking API compatibility at run-time:

guard #available(tvOS 1.0, *) else {
    fatalError("We need a TV.")
}

// Do what we're supposed to do....
We can move the check to compile-time:

#if os(tvOS)
// Do what we're supposed to do....
#else
#error("We need a TV.")
#endif
Detailed design
Add to the "Grammar of a Compiler Control Statement":

compiler-control-statement → error-directive-statement­
Add a new section "Grammar of a Error Directive Statement":

error-directive-statement → #error ( static-string-literal )
The semantics of an error directive statement are: when such a statement is encountered during translation, and it is not in an inactive compilation block branch, compilation is aborted and the directive's string is included in the diagnostic of the directive's source line.

Source compatibility
This proposal should cause no problems with source compatibility. Relative to the current grammar, there is an addition of one token: #error. Since #-leading tokens are illegal except for the explicitly defined ones, there is no possibly of token overlap in legacy code.

Effect on ABI stability
Since the domain of this proposal is all in the compilation phase of creating object code, there is no effect on ABI stability.

Effect on API resilience
The domain of this proposal, controlling whether translation completes, does not affect any API.

Alternatives considered
The alternative is to do nothing. This would mean any checks would stay being delayed into run-time, and calling fatalError or similar functions to avoid implementing uncovered compilation cases.

The original C syntax left open tokens as the message after the #error token. I decided to enclose the message as a string to ease parsing.

Future directions
The original idea for this proposal was a distraction while bringing an adaptation of C++'s static_assert, as defined in its proposal <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html&gt;\. The static_assert is a condition-checking mechanic between assert and #error; Swift already has the former and this proposal would bring the latter. There'd still be no equivalent for static_assert. Another proposal for non-environment compile-time expressions and their use in generic where clauses would relieve most of need for static_assert, but there needs to be either a new construct a declaration-level version or #if/#elseif need to be allowed to access non-environment compile-time expressions.

Acknowledgements
How to Use the C Preprocessor's #error Directive <https://barrgroup.com/embedded-systems/how-to/c-preprocessor-error-directive&gt; by Nigel Jones

···

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

[Gor_Gyolchanyan1 (Gor Gyolchanyan)]

Love it! Except I'd add `warning` as well.

···

On Jun 10, 2017, at 8:15 PM, Daryle Walker via swift-evolution <swift-evolution@swift.org> wrote:

Unconditional Error Messages
Proposal: SE-NNNN <file:///Users/daryle/NNNN-filename.md>
Authors: Daryle Walker <https://github.com/CTMacUser&gt;, Author 2 <https://github.com/swiftdev&gt;
Review Manager: TBD
Status: Awaiting review
During the review process, add the following fields as needed:

Decision Notes: Rationale <https://lists.swift.org/pipermail/swift-evolution/&gt;, Additional Commentary <https://lists.swift.org/pipermail/swift-evolution/&gt;
Bugs: SR-NNNN <Issues · apple/swift-issues · GitHub, SR-MMMM <Issues · apple/swift-issues · GitHub;
Previous Revision: 1 <https://github.com/apple/swift-evolution/blob/...commit-ID.../proposals/NNNN-filename.md&gt;
Previous Proposal: SE-XXXX <file:///Users/daryle/XXXX-filename.md>
Introduction
This proposal adds the error directive, which unconditionally posts a compile-time error.

Swift-evolution thread: Discussion thread topic for that proposal <https://lists.swift.org/pipermail/swift-evolution/&gt;
Motivation
A conditional compilation block permits branches of code based on the compilation conditions.

if compilation condition 1
// statements to compile if compilation condition 1 is true
#elseif compilation condition 2
// statements to compile if compilation condition 2 is true
#else
// statements to compile if both compilation conditions are false
#endif
A block lets at most one of its branches to be incorporated into the compiled module. But compilation always occurs; there is no scenario to flag conditions that should never allow compiling.

When suspending work on a source file for a while, marking where you ended work with an unconditional error message would let the compiler remind you where you left off.

Proposed solution
The solution is to add a new compiler control statement, one that posts a fatal diagnostic during compilation. It can include a message to aid the user on how to change their code.

It's called error, after the C preprocessor directive that has the same effects.

For example, instead of checking API compatibility at run-time:

guard #available(tvOS 1.0, *) else {
    fatalError("We need a TV.")
}

// Do what we're supposed to do....
We can move the check to compile-time:

if os(tvOS)
// Do what we're supposed to do....
#else
error("We need a TV.")
#endif
Detailed design
Add to the "Grammar of a Compiler Control Statement":

compiler-control-statement → error-directive-statement­
Add a new section "Grammar of a Error Directive Statement":

error-directive-statement → error ( static-string-literal )
The semantics of an error directive statement are: when such a statement is encountered during translation, and it is not in an inactive compilation block branch, compilation is aborted and the directive's string is included in the diagnostic of the directive's source line.

Source compatibility
This proposal should cause no problems with source compatibility. Relative to the current grammar, there is an addition of one token: error. Since #-leading tokens are illegal except for the explicitly defined ones, there is no possibly of token overlap in legacy code.

Effect on ABI stability
Since the domain of this proposal is all in the compilation phase of creating object code, there is no effect on ABI stability.

Effect on API resilience
The domain of this proposal, controlling whether translation completes, does not affect any API.

Alternatives considered
The alternative is to do nothing. This would mean any checks would stay being delayed into run-time, and calling fatalError or similar functions to avoid implementing uncovered compilation cases.

The original C syntax left open tokens as the message after the error token. I decided to enclose the message as a string to ease parsing.

Future directions
The original idea for this proposal was a distraction while bringing an adaptation of C++'s static_assert, as defined in its proposal <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html&gt;\. The static_assert is a condition-checking mechanic between assert and error; Swift already has the former and this proposal would bring the latter. There'd still be no equivalent for static_assert. Another proposal for non-environment compile-time expressions and their use in generic where clauses would relieve most of need for static_assert, but there needs to be either a new construct a declaration-level version or if/#elseif need to be allowed to access non-environment compile-time expressions.

Acknowledgements
How to Use the C Preprocessor's error Directive <https://barrgroup.com/embedded-systems/how-to/c-preprocessor-error-directive&gt; by Nigel Jones

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

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

[Beta]

A proposal and implementation of warning exist. It has been judged out of scope for Swift 3 and Swift 4 phase 2.

Compiler Diagnostic Directives

···

On Jun 10, 2017, at 10:15 AM, Daryle Walker via swift-evolution <swift-evolution@swift.org> wrote:

Unconditional Error Messages
Proposal: SE-NNNN <file:///Users/daryle/NNNN-filename.md>
Authors: Daryle Walker <https://github.com/CTMacUser&gt;, Author 2 <https://github.com/swiftdev&gt;
Review Manager: TBD
Status: Awaiting review
During the review process, add the following fields as needed:

Decision Notes: Rationale <https://lists.swift.org/pipermail/swift-evolution/&gt;, Additional Commentary <https://lists.swift.org/pipermail/swift-evolution/&gt;
Bugs: SR-NNNN <Issues · apple/swift-issues · GitHub, SR-MMMM <Issues · apple/swift-issues · GitHub;
Previous Revision: 1 <https://github.com/apple/swift-evolution/blob/...commit-ID.../proposals/NNNN-filename.md&gt;
Previous Proposal: SE-XXXX <file:///Users/daryle/XXXX-filename.md>
Introduction
This proposal adds the error directive, which unconditionally posts a compile-time error.

Swift-evolution thread: Discussion thread topic for that proposal <https://lists.swift.org/pipermail/swift-evolution/&gt;
Motivation
A conditional compilation block permits branches of code based on the compilation conditions.

if compilation condition 1
// statements to compile if compilation condition 1 is true
#elseif compilation condition 2
// statements to compile if compilation condition 2 is true
#else
// statements to compile if both compilation conditions are false
#endif
A block lets at most one of its branches to be incorporated into the compiled module. But compilation always occurs; there is no scenario to flag conditions that should never allow compiling.

When suspending work on a source file for a while, marking where you ended work with an unconditional error message would let the compiler remind you where you left off.

Proposed solution
The solution is to add a new compiler control statement, one that posts a fatal diagnostic during compilation. It can include a message to aid the user on how to change their code.

It's called error, after the C preprocessor directive that has the same effects.

For example, instead of checking API compatibility at run-time:

guard #available(tvOS 1.0, *) else {
    fatalError("We need a TV.")
}

// Do what we're supposed to do....
We can move the check to compile-time:

if os(tvOS)
// Do what we're supposed to do....
#else
error("We need a TV.")
#endif
Detailed design
Add to the "Grammar of a Compiler Control Statement":

compiler-control-statement → error-directive-statement­
Add a new section "Grammar of a Error Directive Statement":

error-directive-statement → error ( static-string-literal )
The semantics of an error directive statement are: when such a statement is encountered during translation, and it is not in an inactive compilation block branch, compilation is aborted and the directive's string is included in the diagnostic of the directive's source line.

Source compatibility
This proposal should cause no problems with source compatibility. Relative to the current grammar, there is an addition of one token: error. Since #-leading tokens are illegal except for the explicitly defined ones, there is no possibly of token overlap in legacy code.

Effect on ABI stability
Since the domain of this proposal is all in the compilation phase of creating object code, there is no effect on ABI stability.

Effect on API resilience
The domain of this proposal, controlling whether translation completes, does not affect any API.

Alternatives considered
The alternative is to do nothing. This would mean any checks would stay being delayed into run-time, and calling fatalError or similar functions to avoid implementing uncovered compilation cases.

The original C syntax left open tokens as the message after the error token. I decided to enclose the message as a string to ease parsing.

Future directions
The original idea for this proposal was a distraction while bringing an adaptation of C++'s static_assert, as defined in its proposal <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html&gt;\. The static_assert is a condition-checking mechanic between assert and error; Swift already has the former and this proposal would bring the latter. There'd still be no equivalent for static_assert. Another proposal for non-environment compile-time expressions and their use in generic where clauses would relieve most of need for static_assert, but there needs to be either a new construct a declaration-level version or if/#elseif need to be allowed to access non-environment compile-time expressions.

Acknowledgements
How to Use the C Preprocessor's error Directive <https://barrgroup.com/embedded-systems/how-to/c-preprocessor-error-directive&gt; by Nigel Jones

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

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

[xwu (Xiaodi Wu)]

Daryle, there have been several pitches in the past with respect to error,
and very enlightening arguments both for and against the idea have been
eloquently written.

Since you’re resurrecting this idea, could I suggest going back through the
archives and linking to and summarizing these arguments, so that we’re not
restarting the discussion from scratch? :)

···

On Sat, Jun 10, 2017 at 13:26 Gor Gyolchanyan via swift-evolution < swift-evolution@swift.org> wrote:

Love it! Except I'd add `warning` as well.

On Jun 10, 2017, at 8:15 PM, Daryle Walker via swift-evolution < > swift-evolution@swift.org> wrote:

Unconditional Error Messages

   - Proposal: SE-NNNN
   - Authors: Daryle Walker <https://github.com/CTMacUser&gt;, Author 2
   <https://github.com/swiftdev&gt;
   - Review Manager: TBD
   - Status: *Awaiting review*

*During the review process, add the following fields as needed:*

   - Decision Notes: Rationale
   <https://lists.swift.org/pipermail/swift-evolution/&gt;, Additional
   Commentary <https://lists.swift.org/pipermail/swift-evolution/&gt;
   - Bugs: SR-NNNN <Issues · apple/swift-issues · GitHub, SR-MMMM
   <Issues · apple/swift-issues · GitHub;
   - Previous Revision: 1
   <https://github.com/apple/swift-evolution/blob/...commit-ID.../proposals/NNNN-filename.md&gt;
   - Previous Proposal: SE-XXXX

Introduction

This proposal adds the error directive, which unconditionally posts a
compile-time error.

Swift-evolution thread: Discussion thread topic for that proposal
<https://lists.swift.org/pipermail/swift-evolution/&gt;
Motivation

A conditional compilation block permits branches of code based on the
compilation conditions.

if compilation condition 1
// statements to compile if compilation condition 1 is true
#elseif compilation condition 2
// statements to compile if compilation condition 2 is true
#else
// statements to compile if both compilation conditions are false
#endif

A block lets at most one of its branches to be incorporated into the
compiled module. But compilation always occurs; there is no scenario to
flag conditions that should never allow compiling.

When suspending work on a source file for a while, marking where you ended
work with an unconditional error message would let the compiler remind you
where you left off.
Proposed solution

The solution is to add a new compiler control statement, one that posts a
fatal diagnostic during compilation. It can include a message to aid the
user on how to change their code.

It's called error, after the C preprocessor directive that has the same
effects.

For example, instead of checking API compatibility at run-time:

guard #available(tvOS 1.0, *) else {
    fatalError("We need a TV.")
}

// Do what we're supposed to do....

We can move the check to compile-time:

if os(tvOS)
// Do what we're supposed to do....
#else
error("We need a TV.")
#endif

Detailed design

Add to the "Grammar of a Compiler Control Statement":

*compiler-control-statement* → *error-directive-statement­*

Add a new section "Grammar of a Error Directive Statement":

*error-directive-statement* → *error* *(* *static-string-literal* *)*

The semantics of an error directive statement are: when such a statement
is encountered during translation, and it is not in an inactive compilation
block branch, compilation is aborted and the directive's string is included
in the diagnostic of the directive's source line.
Source compatibility

This proposal should cause no problems with source compatibility. Relative
to the current grammar, there is an addition of one token: error. Since
#-leading tokens are illegal except for the explicitly defined ones, there
is no possibly of token overlap in legacy code.
Effect on ABI stability

Since the domain of this proposal is all in the compilation phase of
creating object code, there is no effect on ABI stability.
Effect on API resilience

The domain of this proposal, controlling whether translation completes,
does not affect any API.
Alternatives considered

The alternative is to do nothing. This would mean any checks would stay
being delayed into run-time, and calling fatalError or similar functions
to avoid implementing uncovered compilation cases.

The original C syntax left open tokens as the message after the error token.
I decided to enclose the message as a string to ease parsing.
Future directions

The original idea for this proposal was a distraction while bringing an
adaptation of C++'s static_assert, as defined in its proposal
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html&gt;\. The
static_assert is a condition-checking mechanic between assert and error;
Swift already has the former and this proposal would bring the latter.
There'd still be no equivalent for static_assert. Another proposal for
non-environment compile-time expressions and their use in generic where
clauses would relieve most of need for static_assert, but there needs to
be either a new construct a declaration-level version or if/#elseif need
to be allowed to access non-environment compile-time expressions.
Acknowledgements

   - How to Use the C Preprocessor's error Directive
   <https://barrgroup.com/embedded-systems/how-to/c-preprocessor-error-directive&gt; by
   Nigel Jones

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

_______________________________________________
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

[CTMacUser (Daryle Walker)]

Is there somewhere to search the archives?

···

On Jun 10, 2017, at 2:00 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

Daryle, there have been several pitches in the past with respect to error, and very enlightening arguments both for and against the idea have been eloquently written.

Since you’re resurrecting this idea, could I suggest going back through the archives and linking to and summarizing these arguments, so that we’re not restarting the discussion from scratch? :)

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

[benrimmington]

See also "[Pitch] warning" in the mailing lists:

<http://discourse.natecook.com/t/pitch-warning/1727&gt; (35)

<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/thread.html&gt; (11)

<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/thread.html&gt; (24)

···

On 11 Jun 2017, at 19:15, Beta wrote:

A proposal and implementation of warning exist. It has been judged out of scope for Swift 3 and Swift 4 phase 2.

Compiler Diagnostic Directives by harlanhaskins · Pull Request #353 · apple/swift-evolution · GitHub

[xwu (Xiaodi Wu)]

Nate Cook staged a Discourse server that is searchable for a portion of the
archives. A quick Google search will get you there, although at the moment
lists.swift.org doesn’t seem to be responding, so I can’t send you the link
off-hand.

For threads outside the range of that resource, I‘d recommend searching
whatever email archives you have locally, but generally I find that to be
hit-and-miss myself. To get the rest of the way, in the past I’ve manually
combed through all of the weekly archives on lists.swift.org; it’s not fun
but it’s doable.

···

On Sun, Jun 11, 2017 at 05:30 Daryle Walker <darylew@mac.com> wrote:

> On Jun 10, 2017, at 2:00 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
>
> Daryle, there have been several pitches in the past with respect to
error, and very enlightening arguments both for and against the idea have
been eloquently written.
>
> Since you’re resurrecting this idea, could I suggest going back through
the archives and linking to and summarizing these arguments, so that we’re
not restarting the discussion from scratch? :)

Is there somewhere to search the archives?

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

[willft (Will Field-Thompson)]

This is the best I've found for searching the archives:
https://www.google.com/search?q=site%3Ahttps%3A%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F+"%23error"

···

On Sun, Jun 11, 2017 at 11:30 AM Daryle Walker via swift-evolution < swift-evolution@swift.org> wrote:

> On Jun 10, 2017, at 2:00 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
>
> Daryle, there have been several pitches in the past with respect to
error, and very enlightening arguments both for and against the idea have
been eloquently written.
>
> Since you’re resurrecting this idea, could I suggest going back through
the archives and linking to and summarizing these arguments, so that we’re
not restarting the discussion from scratch? :)

Is there somewhere to search the archives?

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

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

[CTMacUser (Daryle Walker)]

A proposal and implementation of warning exist. It has been judged out of scope for Swift 3 and Swift 4 phase 2.

Compiler Diagnostic Directives by harlanhaskins · Pull Request #353 · apple/swift-evolution · GitHub

See also "[Pitch] warning" in the mailing lists:

<http://discourse.natecook.com/t/pitch-warning/1727&gt; (35)

<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/thread.html&gt; (11)

<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019407.html&gt; for the initial post.

<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/thread.html&gt; (24)

<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019524.html&gt; for the initial post broken from the first part.

···

On Jun 12, 2017, at 8:03 AM, Ben Rimmington <me@benrimmington.com> wrote:

On 11 Jun 2017, at 19:15, Beta wrote:

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

[Javi (Javier Soto)]

+1 on adding a compile-time error directive. error seems like the right
syntax as well.
I had a maybe nit-picky comment about the proposal though. I think the
example may not be ideal, since you could accomplish that compile-time
error by annotating the method or class where that code lives with
@available(tvOS) , no?

···

On Sun, Jun 11, 2017 at 9:18 AM Will Field-Thompson via swift-evolution < swift-evolution@swift.org> wrote:

This is the best I've found for searching the archives:
site:https://lists.swift.org/pipermail/swift-evolution/ "#error" - Google Search

On Sun, Jun 11, 2017 at 11:30 AM Daryle Walker via swift-evolution < > swift-evolution@swift.org> wrote:

> On Jun 10, 2017, at 2:00 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
>
> Daryle, there have been several pitches in the past with respect to
error, and very enlightening arguments both for and against the idea have
been eloquently written.
>
> Since you’re resurrecting this idea, could I suggest going back through
the archives and linking to and summarizing these arguments, so that we’re
not restarting the discussion from scratch? :)

Is there somewhere to search the archives?

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

_______________________________________________
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

--
Javier Soto

[CTMacUser (Daryle Walker)]

And:
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019545.html&gt;
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019641.html&gt;
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019774.html&gt;
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019845.html&gt;

But the Discourse site contains most of these.

···

On Jun 12, 2017, at 3:57 PM, Daryle Walker via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 12, 2017, at 8:03 AM, Ben Rimmington <me@benrimmington.com <mailto:me@benrimmington.com>> wrote:

On 11 Jun 2017, at 19:15, Beta wrote:

A proposal and implementation of warning exist. It has been judged out of scope for Swift 3 and Swift 4 phase 2.

Compiler Diagnostic Directives by harlanhaskins · Pull Request #353 · apple/swift-evolution · GitHub

See also "[Pitch] warning" in the mailing lists:

<http://discourse.natecook.com/t/pitch-warning/1727&gt; (35)

<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/thread.html&gt; (11)

<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019407.html&gt; for the initial post.

<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/thread.html&gt; (24)

<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019524.html&gt; for the initial post broken from the first part.

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

[Gor_Gyolchanyan1 (Gor Gyolchanyan)]

I was playing around with Swift's mysterious Builtin module, accessible via the `-parse-stdlib` compiler flag and I noticed a builtin primitive that causes a fatal error if the branch it's in is not optimized away. This seems like an opportunity for a much more powerful "this place is not implemented", where the execution branch analyzer can determine at compile time for specific cases whether or not the unimplemented branch will be accessed. We could make a proposal to introduce a new compiler directive of the following form:

public func #unavailable(_ message: String? = nil) -> Never

This directive would be allowed both in function scope and global scope.
Calls to this directive would generate a compile-time error when the execution path it's located in can be guaranteed and a run-time error in all other cases.
Placing this directive in the global scope would generate a compile-time error unconditionally.

The only way to avoid this error is to either have the call to it optimized away or conditionally compiled out:

if os(macOS)
  import Cocoa
#else
  #unavailalbe("Sorry, pal. I only work with macs.")
#endif

func compare(_ x: Int, _ y: Int) -> Int {
  if x > 0 {
    return 1
  } else if x == 0 {
    return 0
  } else if x < 0 {
    return -1
  } else {
    #unavailable("How the hell did you managed to get here?")
  }
}

···

On Jun 11, 2017, at 7:45 PM, Javier Soto via swift-evolution <swift-evolution@swift.org> wrote:

+1 on adding a compile-time error directive. error seems like the right syntax as well.
I had a maybe nit-picky comment about the proposal though. I think the example may not be ideal, since you could accomplish that compile-time error by annotating the method or class where that code lives with @available(tvOS) , no?
On Sun, Jun 11, 2017 at 9:18 AM Will Field-Thompson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
This is the best I've found for searching the archives: site:https://lists.swift.org/pipermail/swift-evolution/ "#error" - Google Search <site:https://lists.swift.org/pipermail/swift-evolution/ "#error" - Google Search;

On Sun, Jun 11, 2017 at 11:30 AM Daryle Walker via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Jun 10, 2017, at 2:00 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:
>
> Daryle, there have been several pitches in the past with respect to error, and very enlightening arguments both for and against the idea have been eloquently written.
>
> Since you’re resurrecting this idea, could I suggest going back through the archives and linking to and summarizing these arguments, so that we’re not restarting the discussion from scratch? :)

Is there somewhere to search the archives?

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Javier Soto
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution