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