7 ms·

Well for the first round they are looking at: 1. Allowing generalized unicode identifiers. That is hardly likely to break anything except possibly some crazy ed

Well for the first round they are looking at: 1. Allowing generalized unicode identifiers. That is hardly likely to break anything except possibly some crazy edge cases that dont happen in real code. 2. Binary integer literals. (unlikely to break things) 3. allowing seperating groups of digits in a number with _ like 1_000_000 (unlikely to break anything) 4. Permit signed integers as shift counts (no need to cast ant int to a uint to use it in a shift expression. This won't break any existing code). So at least this first round is quite unlikely to break anything in real use.

bryanlarsen 8y ago
For the first round they are testing the GO 2 selection process by applying it to proposed changes for 1.13, which limits it to non-breaking proposals. It won't get interesting until they start selecting breaking proposals.
- stcredzero 8y ago
  It won't get interesting until they start selecting breaking proposals. From what I see in the past couple of decades in popular languages, is there really a justification for breaking changes, from the POV of project maintainers?
  - copperx 8y ago
    That's a good question because they ostensibly do it to get more users aboard, but in most cases, the result is the opposite (e.g., the Python 2/3 disaster).
    - stcredzero 8y ago
      I was actually thinking of the POV of people writing in the language, not the maintainers of the project which is the language. I guess my point is that those two groups of people have different incentives.
    - littlestymaar 8y ago
      The Python 2/3 switch was indeed a disaster, but in term of user gained and lost not so much: the number of Python users skyrocketed since 2007 despite the breakage nightmare.
    - hhmc 8y ago
      C++11 introduced breaking changes (https://stackoverflow.com/questions/6399615/what-breaking-changes-are-introduced-in-c11 https://stackoverflow.com/questions/6399615/what-breaking-ch...) but is widely regarded as a boon to the language.
      - stcredzero 8y ago
        Yes, but in large part, those changes were quite obscure, in comparison to things like how to define classes.
  - fgonzag 8y ago
    .net 2.0 had breaking changes, and it was absolutely justified. The ecosystem would not be where it is now without it. (.net 2.0 introduced reified generics, and required a major overhaul of the internals, with quite a bit of breaking changes)
  - bryanlarsen 8y ago
    Rust 2018 has breaking changes, and their mechanism for dealing with it is incredible.
rootbear 8y ago
I would like to see more Unicode operators, at least as options. It's crazy that we still use * for × in 2018. Yes, I know that most US keyboards don't have that symbol but that's a solvable problem. I use an international layout on my Linux systems and can type it easily. Also, I prefer using ' for the thousands separator and was happy when C++ adopted it. It's less visually intrusive, especially with variable width fonts, and some calculators even use apostrophe. Also, in identifiers, the underscore has semantic meaning: foo_bar is different from foobar. But 1'234'567 is meant to be identical to 1234567, so underscore isn't the best choice.
- acdha 8y ago
  > It's crazy that we still use * for × in 2018. Yes, I know that most US keyboards don't have that symbol but that's a solvable problem. I see the appeal but there are two problems with this: “solvable” is not the same as “easy”, and that similarly also wants fonts which make × more distinct from x. In both cases that's something which is perhaps approachable for dedicated developers but it seems likely to turn newcomers off of the language far more than deliver any real benefit. > the underscore has semantic meaning: foo_bar is different from foobar. But 1'234'567 is meant to be identical to 1234567, so underscore isn't the best choice. It's kind of odd to argue that inconsistency counts against use of the underscore but then argue for adding another distinct use for the apostrophe. That would require care for every tool which works with the language from compilers to highlighters, which seems unlikely to be worth the hassle since, unlike mathematical symbols, there's not much precedent for that convention.
  - rootbear 8y ago
    Prior to some programming languages adopting it, I don't think there was precedent for using underscore as a thousands separator, so I don't consider it a strong precedent. The first language I recall using it was Ada. But I understand that using apostrophe has problems that would likely make its adoption impossible for an existing language. I was actually surprised when C++ adopted it. Interestingly, there is a locale that uses apostrophe for the thousands separator: de_CH (Swiss German). Try this in bash: $ LC_NUMERIC=de_CH df --block-size=\'1KB I don't know if there is a locale that uses underscore, I didn't find one when I looked a while back. Perhaps there should be...

bryanlarsen 8y ago

For the first round they are testing the GO 2 selection process by applying it to proposed changes for 1.13, which limits it to non-breaking proposals. It won't get interesting until they start selecting breaking proposals.

stcredzero 8y ago
It won't get interesting until they start selecting breaking proposals. From what I see in the past couple of decades in popular languages, is there really a justification for breaking changes, from the POV of project maintainers?
- copperx 8y ago
  That's a good question because they ostensibly do it to get more users aboard, but in most cases, the result is the opposite (e.g., the Python 2/3 disaster).
  - stcredzero 8y ago
    I was actually thinking of the POV of people writing in the language, not the maintainers of the project which is the language. I guess my point is that those two groups of people have different incentives.
  - littlestymaar 8y ago
    The Python 2/3 switch was indeed a disaster, but in term of user gained and lost not so much: the number of Python users skyrocketed since 2007 despite the breakage nightmare.
  - hhmc 8y ago
    C++11 introduced breaking changes (https://stackoverflow.com/questions/6399615/what-breaking-changes-are-introduced-in-c11 https://stackoverflow.com/questions/6399615/what-breaking-ch...) but is widely regarded as a boon to the language.
    - stcredzero 8y ago
      Yes, but in large part, those changes were quite obscure, in comparison to things like how to define classes.
- fgonzag 8y ago
  .net 2.0 had breaking changes, and it was absolutely justified. The ecosystem would not be where it is now without it. (.net 2.0 introduced reified generics, and required a major overhaul of the internals, with quite a bit of breaking changes)
- bryanlarsen 8y ago
  Rust 2018 has breaking changes, and their mechanism for dealing with it is incredible.

rootbear 8y ago

I would like to see more Unicode operators, at least as options. It's crazy that we still use * for × in 2018. Yes, I know that most US keyboards don't have that symbol but that's a solvable problem. I use an international layout on my Linux systems and can type it easily. Also, I prefer using ' for the thousands separator and was happy when C++ adopted it. It's less visually intrusive, especially with variable width fonts, and some calculators even use apostrophe. Also, in identifiers, the underscore has semantic meaning: foo_bar is different from foobar. But 1'234'567 is meant to be identical to 1234567, so underscore isn't the best choice.

acdha 8y ago
> It's crazy that we still use * for × in 2018. Yes, I know that most US keyboards don't have that symbol but that's a solvable problem. I see the appeal but there are two problems with this: “solvable” is not the same as “easy”, and that similarly also wants fonts which make × more distinct from x. In both cases that's something which is perhaps approachable for dedicated developers but it seems likely to turn newcomers off of the language far more than deliver any real benefit. > the underscore has semantic meaning: foo_bar is different from foobar. But 1'234'567 is meant to be identical to 1234567, so underscore isn't the best choice. It's kind of odd to argue that inconsistency counts against use of the underscore but then argue for adding another distinct use for the apostrophe. That would require care for every tool which works with the language from compilers to highlighters, which seems unlikely to be worth the hassle since, unlike mathematical symbols, there's not much precedent for that convention.
- rootbear 8y ago
  Prior to some programming languages adopting it, I don't think there was precedent for using underscore as a thousands separator, so I don't consider it a strong precedent. The first language I recall using it was Ada. But I understand that using apostrophe has problems that would likely make its adoption impossible for an existing language. I was actually surprised when C++ adopted it. Interestingly, there is a locale that uses apostrophe for the thousands separator: de_CH (Swiss German). Try this in bash: $ LC_NUMERIC=de_CH df --block-size=\'1KB I don't know if there is a locale that uses underscore, I didn't find one when I looked a while back. Perhaps there should be...