4 ms·

I wonder if there's a future where you have a language model that actually inspects the name of your functions, does an automatic code-gen of them from the cont

I wonder if there's a future where you have a language model that actually inspects the name of your functions, does an automatic code-gen of them from the context and then compares your implementation and gives you lint errors like: fn add() { ... }: mispleading name or incorrect implementation `a - b` You know, once upon a time I would have thought that was categorically impossible, but now, you know, it actually seems like something that might not be that far off. > It's just not something Rust is designed to protect against - at least, not today. ...maybe, one day. :)

eru 5y ago
If you are willing to accept quite a few false positives and false negatives, I think current techniques in machine learning can deliver on this promise. (If you put in all the work to train a good mode etc.) Btw, have a look at hlint. It sometimes gives rather involved hints about how you can restructure your code.
dhosek 5y ago
Isn't this what the autopilot thing is supposed to do kind of? Except it just gives you the auto-generated code.
- melony 5y ago
  Just run the output of autopilot in a symbolic execution environment and diff it against the code paths of the user code. This is one (admittedly convoluted) way of implementing what OP wants.
kgeist 5y ago
This kind of linter would be useful for teams whose native language isn't English (such as ours). They often choose bizarre names for their functions, it's not always clear what a function does by reading its name alone.
- riwsky 5y ago
  I assure you: native English speakers will often choose names that are just as bizarre. Sincerely, Guy Who Once Named A Class RefBursar
  - cozzyd 5y ago
    Pardon me, are you &AaronBurr, sir?
woodruffw 5y ago
> fn add() { ... }: mispleading name or incorrect implementation `a - b` Advice like this is frustratingly non-general: you might be doing addition over GF2[1] in which case `fn add(a, b) { a ^ b }` is a perfectly sound function. I've worked on a codebase, in Rust, where that's the case[2]! [1]: https://en.wikipedia.org/wiki/Finite_field_arithmetic#Effective_polynomial_representation https://en.wikipedia.org/wiki/Finite_field_arithmetic#Effect... [2]: https://github.com/trailofbits/reverie/blob/master/src/algebra/gf2/batch.rs#L49 https://github.com/trailofbits/reverie/blob/master/src/algeb...
- deleted 5y ago
  [deleted]
- xanathar 5y ago
  Linters should be frustatingly non-general. They should alert for the common case and special cases should have a "#[allow(xxx)]" or "#pragma warning disable xxx" (or whatever does that in your language) and, possibly, a comment. This, incidentally, also helps fellow humans reading the code who'll see that it's all intentional and won't flip with "wtf why does it XOR in an add method?" even if just for a second.
  - marcosdumay 5y ago
    Only up to a certain point. If you add a few pragmas before each line of code, your code is not completely illegible. As an example, those linters that have a message for each programing style and a rule to convert between them are stupid. They might be useful as some other kind of code, but as linters they are not just useless, they are actively harmful.
- zild3d 5y ago
  > you might be doing addition over GF2 Then the function name, class, and/or comments should be making that clear! In this case, the BatchGF2 class does so. Maybe somewhere else a Fourier class has `fn add() { a * b } // a and b are in time domain` but a standalone add() function with no comments or class should probably not be doing a ^ b, a - b, or a * b. some github copilot like linter can then draw from other GF2, Fourier, etc code references vs vanilla add functions
zesterer 5y ago
As JoshTriplett said above, Rust's Clippy does this today: https://rust-lang.github.io/rust-clippy/master/#suspicious_arithmetic_impl https://rust-lang.github.io/rust-clippy/master/#suspicious_a...
deleted 5y ago
[deleted]
majewsky 5y ago
It's quite fitting that this sort of thing is dubbed "autopilot", because in all likelihood it will have the same problem as gradually more self-driving cars. There will be a level of automation where the computer still makes errors frequently enough, but the user is sufficiently disconnected from the action that they lose all attentiveness.

eru 5y ago

If you are willing to accept quite a few false positives and false negatives, I think current techniques in machine learning can deliver on this promise. (If you put in all the work to train a good mode etc.) Btw, have a look at hlint. It sometimes gives rather involved hints about how you can restructure your code.

dhosek 5y ago

Isn't this what the autopilot thing is supposed to do kind of? Except it just gives you the auto-generated code.

melony 5y ago
Just run the output of autopilot in a symbolic execution environment and diff it against the code paths of the user code. This is one (admittedly convoluted) way of implementing what OP wants.

kgeist 5y ago

This kind of linter would be useful for teams whose native language isn't English (such as ours). They often choose bizarre names for their functions, it's not always clear what a function does by reading its name alone.

riwsky 5y ago
I assure you: native English speakers will often choose names that are just as bizarre. Sincerely, Guy Who Once Named A Class RefBursar
- cozzyd 5y ago
  Pardon me, are you &AaronBurr, sir?

woodruffw 5y ago

> fn add() { ... }: mispleading name or incorrect implementation `a - b` Advice like this is frustratingly non-general: you might be doing addition over GF2[1] in which case `fn add(a, b) { a ^ b }` is a perfectly sound function. I've worked on a codebase, in Rust, where that's the case[2]! [1]: https://en.wikipedia.org/wiki/Finite_field_arithmetic#Effective_polynomial_representation https://en.wikipedia.org/wiki/Finite_field_arithmetic#Effect... [2]: https://github.com/trailofbits/reverie/blob/master/src/algebra/gf2/batch.rs#L49 https://github.com/trailofbits/reverie/blob/master/src/algeb...

deleted 5y ago
[deleted]
xanathar 5y ago
Linters should be frustatingly non-general. They should alert for the common case and special cases should have a "#[allow(xxx)]" or "#pragma warning disable xxx" (or whatever does that in your language) and, possibly, a comment. This, incidentally, also helps fellow humans reading the code who'll see that it's all intentional and won't flip with "wtf why does it XOR in an add method?" even if just for a second.
- marcosdumay 5y ago
  Only up to a certain point. If you add a few pragmas before each line of code, your code is not completely illegible. As an example, those linters that have a message for each programing style and a rule to convert between them are stupid. They might be useful as some other kind of code, but as linters they are not just useless, they are actively harmful.
zild3d 5y ago
> you might be doing addition over GF2 Then the function name, class, and/or comments should be making that clear! In this case, the BatchGF2 class does so. Maybe somewhere else a Fourier class has `fn add() { a * b } // a and b are in time domain` but a standalone add() function with no comments or class should probably not be doing a ^ b, a - b, or a * b. some github copilot like linter can then draw from other GF2, Fourier, etc code references vs vanilla add functions

zesterer 5y ago

As JoshTriplett said above, Rust's Clippy does this today: https://rust-lang.github.io/rust-clippy/master/#suspicious_arithmetic_impl https://rust-lang.github.io/rust-clippy/master/#suspicious_a...

deleted 5y ago

[deleted]

majewsky 5y ago

It's quite fitting that this sort of thing is dubbed "autopilot", because in all likelihood it will have the same problem as gradually more self-driving cars. There will be a level of automation where the computer still makes errors frequently enough, but the user is sufficiently disconnected from the action that they lose all attentiveness.