C++17 Features That Will Make Your Code Simpler

Struct X could have a constructor

   public X(int first,int second):a{first},b{second}

This sort of easily detected error is exactly the same as writing [b,a] instead of [a,b] in a deconstructing assignment.

Treating a sequence of fields in a class as a tuple is "unusual and slightly flaky" because few and unimportant languages do it, because it's very new for C++, and because it faces complications like inheritance, not because it is wrong or bad; someone might be slow to adapt, but everyone else will benefit.

In practice, only very plain and well documented structs will be suitable for deconstructing assignment; for example, in code generated from data serialization schemas there is a natural and well known order for class members.

This is terrible for safety. Which is not surprising in a long line of questionable language design choices made for C++.

then... just use the struct directly if that's what you want ? But a single binding can map to multiple structs, especially in generic code :

    template<typename T>
    double dist(T point) { 
      auto& [x, y] = point;
      return std::sqrt(x * x + y * y);
    }

    struct Point { float f[2]; }

    struct Point { float x, y; }

    struct Point { float p1, p2; }

    std::tuple<float, float>

When someone new comes into a project, you can’t assume what skill level they’re at, how they think about code, what design patterns have been most strongly used in the teams they were previously on.

Code you wrote a few weeks ago is still going to be hugely similar to the types of code you often write, the ways you think about design patterns, etc., especially if you’re on a team for a long time.

Code someone else wrote very frequently looks completely alien, especially for new people, or someone from a different team that has to collaborate on one small cross-cutting problem, or people who look at your code long after you left the company.

Using things like auto because it has some benefit as you write the code, in your mind, is deceptive for exactly this reason. Those criteria are hardly ever still relevant when it is someone else reading the code.

I’m all for shorter syntax, just not at the expense of completely explicit type annotation.

Needing to constantly switch things by creating different sets of headers with different groups of typedefs, and then rely on the codebase to have happened to use auto in just the right ways that things still compile correctly with the swapped-in types is horrible.

Like, absolutely amateur, risk of getting fired level of badness. I can scarcely think of a way to design system-level polymorphism that would be more directly hostile to new developers or other people maintaining your code than the approach you’re describing.

This sounds like the type of pathology when a developer creates a needlessly complex system purely for rent-seeking and job security. You’ve built a system nobody else can maintain because ever so slight changes to the way it uses auto can bring down the whole house of cards from your variety of special header files. Nobody else wants to catch that falling sword, so when they have to work on or change that code, they just tiptoe on eggshells to mimic whatever existing use of auto there is, out of complete fear that more specific type annotation is going to break things. This is not a hallmark of a good project. More like painting everyone else into a corner that only you happen to prefer.

It sounds crazy to me to hear someone say that it’s OK to tolerate the downsides of a language feature because some other tool like an IDE might mitigate them in some cases.

Why are we contorting our tools to overcome language problems and acting like it’s OK, instead of designing better languages in the first place that don’t require tooling gymnastics to make them readable?

for(my_vector_t::const_iterator it = v.cbegin(), end = v.cend(); it != end; ) { ... }

and if that looks long, then the problem is poor choice of type names in STL. I.e if the const_iterator would be citer, then with

    for(my_vector_t::citer it = v.cbegin(), end = v.cend(); it != end; ) {
    ...
    }

    for(sized_t i = 0; i != v.size(); ) {
        if (v[i].second > 1 && i % rand() == 0) {
            v.erase(v.begin() + i);
        else
            ++i;
    } 

Surely the code only works with vectors, but when one deals with vector of pairs, it implies very specific problem that rather unlikely to change. It also show that the need for auto really comes from the design of STL that leads to very long types that auto mitigates.

This is very false, I can tell you from having written Haskell in production for several years. It’s widely regarded as an anti-pattern in Haskell to leave out type annotations, even for constant values, except in the most trivial of cases.

Type annotations are a design feature of Haskell. You usually use the “type” keyword to define custom type names for primitive types just to give them descriptive, application-specific names, like

type PhoneBook = [(Name, Number)]

just so you can add more explicit annotations and communicate the flow of your program very explicitly in the type annotations.

You definitely do not look at it like minimally using type annotations “only where it adds clarity” because the whole point is that as the code author you don’t know where clarity is needed. That is for the code reader who has to change your work later on.

Incidentally, I actually very much think that your first example of that for loop at the bottom is a lot clearer than the one using auto.

Just make a descriptive typedef / typename of that long const_iterator type. Make something readable so that we know why there is a vector of pairs of (float, int).

If you want to cut down the syntax there, auto is not the right way. A descriptive typedef is the right way using type alias names that communicate your intended design.