Proposal: Allow functions to participate in the compile so they can generate warnings about their usage.


(Amir Michail) #1

For example, the Swift standard library might want to ensure that you use "preconditionFailure()" instead of "precondition(false)" since the former doesn’t get in the way of constant/variable initialization static analysis.

So maybe allow functions to have a warning clause with an abstract syntax tree parameter allowing the function to examine its usage context in the source code and issue warnings correspondingly that appear during the compile.

Here’s some related work: https://msdn.microsoft.com/en-us/magazine/dn879356.aspx


(Andrew Bennett) #2

Fantastic idea, it would be nice to be able to do this in such a way that
it didn't bloat out a function's definition. This is similar to the
code-by-contract discussions that have happened in the past. This may be
breaking into macro territory though. Perhaps it could be expressed like
this:

@callVerification func verifyNoLiterals(inNode node: ASTNode) ->
[CallVerificationError] {
    ...
}

@verifyCall(noLiterals)
func precondition(success: Bool) {
    ...
}

···

On Sat, Feb 13, 2016 at 8:15 AM, Amir Michail via swift-evolution < swift-evolution@swift.org> wrote:

For example, the Swift standard library might want to ensure that you use
"preconditionFailure()" instead of "precondition(false)" since the former
doesn’t get in the way of constant/variable initialization static analysis.

So maybe allow functions to have a warning clause with an abstract syntax
tree parameter allowing the function to examine its usage context in the
source code and issue warnings correspondingly that appear during the
compile.

Here’s some related work:
https://msdn.microsoft.com/en-us/magazine/dn879356.aspx

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


(Amir Michail) #3

Fantastic idea, it would be nice to be able to do this in such a way that it didn't bloat out a function's definition. This is similar to the code-by-contract discussions that have happened in the past. This may be breaking into macro territory though. Perhaps it could be expressed like this:

BTW, you might want to check out this related work as well:

http://types.cs.washington.edu/checker-framework/
http://types.cs.washington.edu/checker-framework/tutorial/webpages/user-input-eclipse.html
http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html#writing-a-checker

···

On Feb 13, 2016, at 10:39 PM, Andrew Bennett <cacoyi@gmail.com> wrote:

@callVerification func verifyNoLiterals(inNode node: ASTNode) -> [CallVerificationError] {
    ...
}

@verifyCall(noLiterals)
func precondition(success: Bool) {
    ...
}

On Sat, Feb 13, 2016 at 8:15 AM, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
For example, the Swift standard library might want to ensure that you use "preconditionFailure()" instead of "precondition(false)" since the former doesn’t get in the way of constant/variable initialization static analysis.

So maybe allow functions to have a warning clause with an abstract syntax tree parameter allowing the function to examine its usage context in the source code and issue warnings correspondingly that appear during the compile.

Here’s some related work: https://msdn.microsoft.com/en-us/magazine/dn879356.aspx

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


(Andrew Bennett) #4

Thanks. I wonder if you could use a linter, if you can add some
documentation to a function that the linter can pick up then it's possible
to do this now.

···

On Monday, 15 February 2016, Amir Michail <a.michail@me.com> wrote:

On Feb 13, 2016, at 10:39 PM, Andrew Bennett <cacoyi@gmail.com > <javascript:_e(%7B%7D,'cvml','cacoyi@gmail.com');>> wrote:

Fantastic idea, it would be nice to be able to do this in such a way that
it didn't bloat out a function's definition. This is similar to the
code-by-contract discussions that have happened in the past. This may be
breaking into macro territory though. Perhaps it could be expressed like
this:

BTW, you might want to check out this related work as well:

http://types.cs.washington.edu/checker-framework/

http://types.cs.washington.edu/checker-framework/tutorial/webpages/user-input-eclipse.html

http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html#writing-a-checker

@callVerification func verifyNoLiterals(inNode node: ASTNode) ->
[CallVerificationError] {
    ...
}

@verifyCall(noLiterals)
func precondition(success: Bool) {
    ...
}

On Sat, Feb 13, 2016 at 8:15 AM, Amir Michail via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

For example, the Swift standard library might want to ensure that you use
"preconditionFailure()" instead of "precondition(false)" since the former
doesn’t get in the way of constant/variable initialization static analysis.

So maybe allow functions to have a warning clause with an abstract syntax
tree parameter allowing the function to examine its usage context in the
source code and issue warnings correspondingly that appear during the
compile.

Here’s some related work:
https://msdn.microsoft.com/en-us/magazine/dn879356.aspx

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution