5 ms·

The is/as pair seems like a tremendous improvement to the dismal C++ type inspection and casting status quo. However I'm a bit suspect of language syntax that

by pavlov 4y ago

The is/as pair seems like a tremendous improvement to the dismal C++ type inspection and casting status quo. However I'm a bit suspect of language syntax that superficially appeals to plain-English meaning of contrasting words, but adds a cognitive overload. I'm thinking of how JavaScript has both `for...in` and `for...of` — the everyday usage of the "in" and "of" prepositions provides no guidance to what these words mean in JavaScript iteration.

llanowarelves 4y ago
I bounce between languages for different projects (work, home) and I have to look up examples for how to those JavaScript ones all the time.
- seedboot 4y ago
  A great way to remember: Objects have keys -> foreign keys -> `for .. in`
- Etheryte 4y ago
  The mnemonic I use is "for index", as in for keys you can use to index things. One gotcha to remember here is that officially all property names are strings [0], and that includes array indexes. To exemplify, `for (let x in { a: 40, b: 41, c: 42 }) { console.log(x); }` would give you "a", "b", "c" as that's what you can use as an index to key into that object to get the values. And `for (let x in [40, 41, 42]) { console.log(x); }` would give you "0", "1", "2" as that what's you can use as an index to key into that object. I always remember `for..of` as just the other one. [0] https://stackoverflow.com/q/27537677/1470607 https://stackoverflow.com/q/27537677/1470607
- masklinn 4y ago
  The trick is to remember that “for in” is the obvious one, meaning it’s the older one, meaning it’s the one that’s next to useless and should almost never be used.
0xfaded 4y ago
In "The C++ Programming Language", casting is described as a tool of last resort. Bjarne says he likes long winded cast operators because they stand out as an easily greppable marker of complex code. I wonder if this perception is changing. Personally I like the explicit names, even if I can appreciate the argument that the proposed mechanism makes the templating system more generic.
- water8 4y ago
  In general, you should know what objects you are sending and receiving, and it shouldn’t be a mystery that requires reinterpreting
  - arinlen 4y ago
    > In general, you should know what objects you are sending and receiving, and it shouldn’t be a mystery that requires reinterpreting You should know what's the interface that you're sending/receiving, but if you're planning on making downcasts then either you're doing something very exotic or you should take a step back and reevaluate what you're doing. I'm seeing a lot of people in this thread complaining about features being added to C++ that improve developer experience, but barely anyone complaining that shooting yourself in the foot requires making intentional choices to get your feet in front of your guns.
    - TremendousJudge 4y ago
      In school I learned about inheritance, not composition. The usual: base "shape" class, then subclasses triangle, square, circle, etc. Then you can have a collection of "shape"s that know what they are. What I've read online indicates it's the same for most other people (who learned in a formal context, anyway). This way of doing things necessitates downcasting; at some point you're converting shape into a triangle or whatever, to access some specific method it has. I'm not saying this is the right way of doing things (I don't think so), but many people expect this to be possible to do easily -- and it isn't. For them this is normal and not "something very exotic". I guess this is the source of the misunderstanding and the complaints.
beeforpork 4y ago
> 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.
IshKebab 4y ago
JavaScript's for in/of were not intended to be like that. `in` is broken so in a world without backwards compatibility to worry about they would have just fixed it to have the behaviour of `of`. But because they had to consider backwards compatibility they had to come up with a new name. You should basically never use `for in`. I guess part of the problem is that making that clear in most languages is easy - just add a compiler warning. But JavaScript requires users to manually set up and configure ESLint and if you know how to do that you probably already know not to use `for in` anyway. I guess modern runtimes like Deno might help here.
- rascul 4y ago
  What is broken about for in? A quick search didn't turn up anything for me. I don't write much Javascript but for the times I do this seems like it could be useful information for me.
  - layer8 4y ago
    You need to up your Google-foo. E.g.: https://stackoverflow.com/questions/500504/why-is-using-for-in-for-array-iteration-a-bad-idea https://stackoverflow.com/questions/500504/why-is-using-for-...
    - pavlov 4y ago
      That talks about using for…in with arrays, but not plain objects. IMO it’s fine for iterating over object keys. Sure, there are bizarre ways to make your objects go nuts in JavaScript through prototypal inheritance, but if you’re doing that then for…in is not your biggest problem.
      - IshKebab 4y ago
        You shouldn't normally need to iterate over object keys. Doing so is a pretty big indication of bad design. If you do you should use `Object.entries()` which avoids enumerating properties in the prototype chain. There's really no reason at all to use for-in and its use is usually a mistake.
shadowofneptune 4y ago
The classic example is the keyword 'else,' when the proper English term in that sotution would be 'otherwise.'
- Karellen 4y ago
  > the highest level--the root--of the [Unix] filesystem is always designated with the single character "/" and it always contains the same set of top-level directories [...] Note the obsessive use of abbreviations and avoidance of capital letters; this is a system invented by people to whom repetitive stress disorder is what black lung is to miners. Long names get worn down to three-letter nubbins, like stones smoothed by a river. -- Neal Stephenson, In The Beginning... Was The Command Line, 1999 But also note that sometimes the people who make these decisions later realise that they went too far: > Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: "I'd spell creat with an e." -- Kernighan & Pike, The UNIX Programming Environment, 1984
- samatman 4y ago
  'else' is archaic, rather than wrong. A quote from Shakespeare's Cybeline: If Caesar can hide the sun from us with a blanket, or put the moon in his pocket, we will pay him tribute for light; else, sir, no more tribute, pray you now. If / else is perfectly clear and correct grammar, though we don't use it in modern speech. We've not chosen 'otherwise', else we waste five columns to no end.
ajkjk 4y ago
Well, JS's for...in/for...of is just a disaster. It's not an example of regular English words being used _well_ in a language.

by pavlov 4y ago

llanowarelves 4y ago

I bounce between languages for different projects (work, home) and I have to look up examples for how to those JavaScript ones all the time.

seedboot 4y ago
A great way to remember: Objects have keys -> foreign keys -> `for .. in`
Etheryte 4y ago
The mnemonic I use is "for index", as in for keys you can use to index things. One gotcha to remember here is that officially all property names are strings [0], and that includes array indexes. To exemplify, `for (let x in { a: 40, b: 41, c: 42 }) { console.log(x); }` would give you "a", "b", "c" as that's what you can use as an index to key into that object to get the values. And `for (let x in [40, 41, 42]) { console.log(x); }` would give you "0", "1", "2" as that what's you can use as an index to key into that object. I always remember `for..of` as just the other one. [0] https://stackoverflow.com/q/27537677/1470607 https://stackoverflow.com/q/27537677/1470607
masklinn 4y ago
The trick is to remember that “for in” is the obvious one, meaning it’s the older one, meaning it’s the one that’s next to useless and should almost never be used.

0xfaded 4y ago

In "The C++ Programming Language", casting is described as a tool of last resort. Bjarne says he likes long winded cast operators because they stand out as an easily greppable marker of complex code. I wonder if this perception is changing. Personally I like the explicit names, even if I can appreciate the argument that the proposed mechanism makes the templating system more generic.

water8 4y ago
In general, you should know what objects you are sending and receiving, and it shouldn’t be a mystery that requires reinterpreting
- arinlen 4y ago
  > In general, you should know what objects you are sending and receiving, and it shouldn’t be a mystery that requires reinterpreting You should know what's the interface that you're sending/receiving, but if you're planning on making downcasts then either you're doing something very exotic or you should take a step back and reevaluate what you're doing. I'm seeing a lot of people in this thread complaining about features being added to C++ that improve developer experience, but barely anyone complaining that shooting yourself in the foot requires making intentional choices to get your feet in front of your guns.
  - TremendousJudge 4y ago
    In school I learned about inheritance, not composition. The usual: base "shape" class, then subclasses triangle, square, circle, etc. Then you can have a collection of "shape"s that know what they are. What I've read online indicates it's the same for most other people (who learned in a formal context, anyway). This way of doing things necessitates downcasting; at some point you're converting shape into a triangle or whatever, to access some specific method it has. I'm not saying this is the right way of doing things (I don't think so), but many people expect this to be possible to do easily -- and it isn't. For them this is normal and not "something very exotic". I guess this is the source of the misunderstanding and the complaints.

beeforpork 4y ago

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

IshKebab 4y ago

JavaScript's for in/of were not intended to be like that. `in` is broken so in a world without backwards compatibility to worry about they would have just fixed it to have the behaviour of `of`. But because they had to consider backwards compatibility they had to come up with a new name. You should basically never use `for in`. I guess part of the problem is that making that clear in most languages is easy - just add a compiler warning. But JavaScript requires users to manually set up and configure ESLint and if you know how to do that you probably already know not to use `for in` anyway. I guess modern runtimes like Deno might help here.

rascul 4y ago
What is broken about for in? A quick search didn't turn up anything for me. I don't write much Javascript but for the times I do this seems like it could be useful information for me.
- layer8 4y ago
  You need to up your Google-foo. E.g.: https://stackoverflow.com/questions/500504/why-is-using-for-in-for-array-iteration-a-bad-idea https://stackoverflow.com/questions/500504/why-is-using-for-...
  - pavlov 4y ago
    That talks about using for…in with arrays, but not plain objects. IMO it’s fine for iterating over object keys. Sure, there are bizarre ways to make your objects go nuts in JavaScript through prototypal inheritance, but if you’re doing that then for…in is not your biggest problem.
    - IshKebab 4y ago
      You shouldn't normally need to iterate over object keys. Doing so is a pretty big indication of bad design. If you do you should use `Object.entries()` which avoids enumerating properties in the prototype chain. There's really no reason at all to use for-in and its use is usually a mistake.

shadowofneptune 4y ago

The classic example is the keyword 'else,' when the proper English term in that sotution would be 'otherwise.'

Karellen 4y ago
> the highest level--the root--of the [Unix] filesystem is always designated with the single character "/" and it always contains the same set of top-level directories [...] Note the obsessive use of abbreviations and avoidance of capital letters; this is a system invented by people to whom repetitive stress disorder is what black lung is to miners. Long names get worn down to three-letter nubbins, like stones smoothed by a river. -- Neal Stephenson, In The Beginning... Was The Command Line, 1999 But also note that sometimes the people who make these decisions later realise that they went too far: > Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: "I'd spell creat with an e." -- Kernighan & Pike, The UNIX Programming Environment, 1984
samatman 4y ago
'else' is archaic, rather than wrong. A quote from Shakespeare's Cybeline: If Caesar can hide the sun from us with a blanket, or put the moon in his pocket, we will pay him tribute for light; else, sir, no more tribute, pray you now. If / else is perfectly clear and correct grammar, though we don't use it in modern speech. We've not chosen 'otherwise', else we waste five columns to no end.

ajkjk 4y ago

Well, JS's for...in/for...of is just a disaster. It's not an example of regular English words being used _well_ in a language.