4 ms·

> The is/as pair seems like a tremendous improvement to the dismal C++ type inspection and casting status quo. No, unfortunately, it further complicates C++, b

> The is/as pair seems like a tremendous improvement to the dismal C++ type inspection and casting status quo. No, unfortunately, it further complicates C++, because the original ways of expressing the same thing will not be removed. You'll just need to remember another level of sugar, but must not forget the lower levels -- e.g., if you want to extend your own type to work with this, you'll need to provide the right plugin definitions. I was especially appalled by the 'x.get()' and 'x.value()' equivalences -- this is just a layer of obfuscation. That table Herb provides will be added to C++ -- but nothing will be removed.

arinlen 4y ago
> No, unfortunately, it further complicates C++, because the original ways of expressing the same thing will not be removed. This is a very unwise and shortsighted take. Not deprecating features right away means everyone's life is made easier as you can upgrade manage full/partial project upgrades to newer C++ standards without having to resort to tickets blocking your critical path with all-or-nothing upgrades. And this does not stop at your projects. Dependencies are also covered. Do you believe it's in your best interests that you lose your ability to up point releases to your Lastly, why does it bother you that backwards compatibility is a Hallmark of C++, and deprecation is a multi-standard process? You're free to stick to a subset if that's what you want. What's the point of getting all bothered with being able to continue using features without seeing them break under your nose for no reason other than a version bump?
- TremendousJudge 4y ago
  Not GP, but what bothers me is that this attitude does not take into account what most cpp programmers actually end up doing: Unless there's somebody at the top of the organization that can set the "right" rules at the start of the project, a novice won't know to use the "right" feature. And neither will somebody who comes from other cpp projects that only had the old way of doing things. The result: a codebase with every possible way of doing a thing, which is strictly worse than one where only one way is used, even if it's not the prettiest. Now if you want to work on it you need to know about everything. Every new feature just increases the need for overhead knowledge. It's almost unavoidable. So, complaining about this would be an unwise shortsighted take in other languages maybe, that don't have the proven track record of just leaving 10 different ways of doing the same thing on the standard. In cpp it's just the voice of somebody who has been burned one too many times by that kind of feature optimism.
  - arinlen 4y ago
    > Not GP, but what bothers me is that this attitude does not take into account what most cpp programmers actually end up doing: Unless there's somebody at the top of the organization that can set the "right" rules at the start of the project, a novice won't know to use the "right" feature. Unless we're discussing single-developer projects, you'd be hard-pressed to find a single project that does not employ any sort of code reviews,where more seasoned developers have a say in each and every change that's proposed. If a project is manned by inexperienced novices, the language is not to blame for the developer's regrettable choices. > The result: a codebase with every possible way of doing a thing, which is strictly worse than one where only one way is used, even if it's not the prettiest. This is outright incompetence, as it violates basic software engineering principles like the principle of least surprise. If a project repeatedly surprised developers with multiple fancy ways of doing the same thing and developers don't put time aside to fix that, the tech stack in use is not a factor in this problem.

arinlen 4y ago

> No, unfortunately, it further complicates C++, because the original ways of expressing the same thing will not be removed. This is a very unwise and shortsighted take. Not deprecating features right away means everyone's life is made easier as you can upgrade manage full/partial project upgrades to newer C++ standards without having to resort to tickets blocking your critical path with all-or-nothing upgrades. And this does not stop at your projects. Dependencies are also covered. Do you believe it's in your best interests that you lose your ability to up point releases to your Lastly, why does it bother you that backwards compatibility is a Hallmark of C++, and deprecation is a multi-standard process? You're free to stick to a subset if that's what you want. What's the point of getting all bothered with being able to continue using features without seeing them break under your nose for no reason other than a version bump?

TremendousJudge 4y ago
Not GP, but what bothers me is that this attitude does not take into account what most cpp programmers actually end up doing: Unless there's somebody at the top of the organization that can set the "right" rules at the start of the project, a novice won't know to use the "right" feature. And neither will somebody who comes from other cpp projects that only had the old way of doing things. The result: a codebase with every possible way of doing a thing, which is strictly worse than one where only one way is used, even if it's not the prettiest. Now if you want to work on it you need to know about everything. Every new feature just increases the need for overhead knowledge. It's almost unavoidable. So, complaining about this would be an unwise shortsighted take in other languages maybe, that don't have the proven track record of just leaving 10 different ways of doing the same thing on the standard. In cpp it's just the voice of somebody who has been burned one too many times by that kind of feature optimism.
- arinlen 4y ago
  > Not GP, but what bothers me is that this attitude does not take into account what most cpp programmers actually end up doing: Unless there's somebody at the top of the organization that can set the "right" rules at the start of the project, a novice won't know to use the "right" feature. Unless we're discussing single-developer projects, you'd be hard-pressed to find a single project that does not employ any sort of code reviews,where more seasoned developers have a say in each and every change that's proposed. If a project is manned by inexperienced novices, the language is not to blame for the developer's regrettable choices. > The result: a codebase with every possible way of doing a thing, which is strictly worse than one where only one way is used, even if it's not the prettiest. This is outright incompetence, as it violates basic software engineering principles like the principle of least surprise. If a project repeatedly surprised developers with multiple fancy ways of doing the same thing and developers don't put time aside to fix that, the tech stack in use is not a factor in this problem.