zlacker

>>orph+(OP)
Copilot is crazy. The other day, I was writing a Python function that would call a Wikipedia API. I pulled from the internet an example of a GET request, and pasted it as a comment in my code.

  # sample call: https://en.wikipedia.org/w/api.php?action=query&format=json&list=geosearch&gscoord=37.7891838%7C-122.4033522&gsradius=10000&gslimit=100

Then I defined a variable,

  base_url = "https://en.wikipedia.org/w/api.php?"

Then, like magic, Copilot suggested all the remaining keys that would go in the query params. It even knew which params were to be kept as-is, and which ones would come from my previous code:

  action = "query"  # action=query
  format = "json"  # or xml
  lat = str(latitude.value)  # 37.7891838
  lon = str(longitude.value)  # -122.4033522
  gscoord = lat + "%7C" + lon
  ...
  api_path = base_url + "action=" + action + "&format=" + format + ... + "&gscoord=" + gscoord

As a guy who gets easily distracted while programming, Copilot saves me a lot of time and keeps me engaged with my work. I can only imagine what it'll look like 10 years from now.

>>pugets+Nr
Yesterday I tried to convert the representation of a number into another representation/type in Rust:

    let coeff = BigUint::from_str(x).unwrap();
    let coeff: <<G1Affine as AffineCurve>::ScalarField as PrimeField>::BigInt =
        coeff.try_into().unwrap();
    let x: <G1Affine as AffineCurve>::ScalarField = coeff.into();

I wrote that, then I wanted to move that code in a function so I wrote:

    fn string_int_to_field_el(s: &str)

copilot suggested the following one-liner that did exactly the same thing:

    fn string_int_to_field_el(s: &str) -> <G1Affine as AffineCurve>::ScalarField {
        let x: <G1Affine as AffineCurve>::ScalarField = s.parse().unwrap();
        x
    }

I still don't understand how some heuristics could produce this code. It's mind blowing.