3 ms·

> Yes, you could make the same mistake without auto, but it's easier to notice. Is it really? I rather think that a missing & is easier to spot with "auto" sim

> Yes, you could make the same mistake without auto, but it's easier to notice. Is it really? I rather think that a missing & is easier to spot with "auto" simply because there is less text to parse for the eye. > If you see "for (auto v : vec)" looks good right? For me the missing & sticks out like a sore thumb. > It's easy to forget (or not notice) that auto will not resolve to a reference in this case Every feature can be misused if the user forgets how it works. I don't think people suddenly forget how "auto" works, given how ubiquitous it is.

tialaramex 10mo ago
It's a foot gun. Why is the default target for this gun my foot? "You should be careful to choose the target properly" isn't an answer to that question.
- gpderetta 10mo ago
  In what way it is a footgun? auto x = ... ; does what I would expect. Copying is usually the default in C++ and that's what I would expect to happen here. If auto deduced reference types transparently, it would actually be more dangerous.
  - spacechild1 10mo ago
    That's exactly what I was about to write!
  - tialaramex 10mo ago
    Copying is a weird default because who said that's even achievable, let alone cheap? So I guess I depart from you there and thus my issue here is not really about auto
    - spacechild1 10mo ago
      C++ has value semantics, which means that values of user-defined types generally behave like values of built-in types. In this sense, copying is the only logical default. It's just how the language has been designed. Things are different in Rust because of lifetimes and destructive moves. In this context, copying would be a bad default indeed. > because who said that's even achievable, let alone cheap? Nobody said that. The thing is that user-defined types can be anything from tiny and cheap to huge and expensive. A language has to pick one default and be consistent. You can complain one way or the other.
      - 1718627440 10mo ago
        I find passing by value to be sensible, but the allocating part sounds like a bad idea. Passing the value of something doesn't imply making a copy, if the value is never changed, it can be entirely optimized away.
        spacechild1 10mo ago
        > Passing the value of something doesn't imply making a copy Yes, languages like Rust can automatically move variables if the compiler can prove that they will not be used anymore. Unfortunately, this is not possible in C++, so the user has to move explicitly (with std::move).
        1718627440 10mo ago
        > Unfortunately, this is not possible in C++, so the user has to move explicitly (with std::move). Honestly why not? A locally used variable sounds to be very much something the compiler can reason about. And a variable only declared in a loop, which is destroyed at the end of each iteration and only read from should be able to be optimized away. I don't know Rust, I mostly write C.
        spacechild1 10mo ago
        Yes, this could work for simple cases, but this breaks down pretty quickly: void checkFoo(const Foo&); Foo getFoo(); void example() { std::vector<Foo> vec; Foo foo = getFoo(); if (checkFoo(foo)) { // *We* know that checkFoo() does not store a // reference to 'foo' but the compiler does not // know this. Therefore it cannot automatically // move 'foo' into the std::vector. vec.push_back(std::move(foo)); } } The fundamental problem is that C++ does not track object lifetimes. You would end up with a system where the compiler would move objects only under certain circumstances, which would be very hard to reason about.
        1718627440 10mo ago

tialaramex 10mo ago

It's a foot gun. Why is the default target for this gun my foot? "You should be careful to choose the target properly" isn't an answer to that question.

gpderetta 10mo ago
In what way it is a footgun? auto x = ... ; does what I would expect. Copying is usually the default in C++ and that's what I would expect to happen here. If auto deduced reference types transparently, it would actually be more dangerous.
- spacechild1 10mo ago
  That's exactly what I was about to write!
- tialaramex 10mo ago
  Copying is a weird default because who said that's even achievable, let alone cheap? So I guess I depart from you there and thus my issue here is not really about auto
  - spacechild1 10mo ago
    C++ has value semantics, which means that values of user-defined types generally behave like values of built-in types. In this sense, copying is the only logical default. It's just how the language has been designed. Things are different in Rust because of lifetimes and destructive moves. In this context, copying would be a bad default indeed. > because who said that's even achievable, let alone cheap? Nobody said that. The thing is that user-defined types can be anything from tiny and cheap to huge and expensive. A language has to pick one default and be consistent. You can complain one way or the other.
    - 1718627440 10mo ago
      I find passing by value to be sensible, but the allocating part sounds like a bad idea. Passing the value of something doesn't imply making a copy, if the value is never changed, it can be entirely optimized away.
      - spacechild1 10mo ago
        > Passing the value of something doesn't imply making a copy Yes, languages like Rust can automatically move variables if the compiler can prove that they will not be used anymore. Unfortunately, this is not possible in C++, so the user has to move explicitly (with std::move).
        1718627440 10mo ago
        > Unfortunately, this is not possible in C++, so the user has to move explicitly (with std::move). Honestly why not? A locally used variable sounds to be very much something the compiler can reason about. And a variable only declared in a loop, which is destroyed at the end of each iteration and only read from should be able to be optimized away. I don't know Rust, I mostly write C.
        spacechild1 10mo ago
        Yes, this could work for simple cases, but this breaks down pretty quickly: void checkFoo(const Foo&); Foo getFoo(); void example() { std::vector<Foo> vec; Foo foo = getFoo(); if (checkFoo(foo)) { // *We* know that checkFoo() does not store a // reference to 'foo' but the compiler does not // know this. Therefore it cannot automatically // move 'foo' into the std::vector. vec.push_back(std::move(foo)); } } The fundamental problem is that C++ does not track object lifetimes. You would end up with a system where the compiler would move objects only under certain circumstances, which would be very hard to reason about.
        1718627440 10mo ago