Well, replacing `static_cast<T>(x)` with `<T>(x)` is obviously not a good idea. You shouldn't waste the Committee's time with that.

But if you want to get involved in that area, I think it would be productive (although there'd be vastly more thinking involved) to look at the existing functional-cast syntax and work on making it Do The Right Thing more often.

C++ has many many cast syntaxes already (which is why we don't need one more):

  reinterpret_cast<T>(x)

  const_cast<T>(x)

  dynamic_cast<T>(x)

  std::bit_cast<T>(x)  [put into the library for some reason]

  static_cast<T>(x)

  T(x) and T() and T(x,y)  [this is the most important one, because it's the most commonly used and the only syntax that exists in most other mainstream languages]

  T{x} and T{} and T{x,y}

  (T)x and (T){} and (T){x,y}

The `T(x)` syntax has at least two big pitfalls:

I think a proposal in that area — to make `T(x)` relatively "safer" through a years-long process of deprecating the dangerous meanings — would be helpful and appreciated.

We shouldn't touch the C-compatibility meaning of `(int)ptr`, for example; but it doesn't seem there's any sensible reason for `int(ptr)` to exist. Functional-style casts that are equivalent to reinterpret_casts could be deprecated.

...Or could they?  Today, I can write

    struct BigInteger { explicit BigInteger(void *ptr); };

    auto x = int(ptr);  // OK, reinterpret_cast

    auto y = BigInteger(ptr);  // OK, explicit conversion

but I believe if we restrict ourselves to keyword casts only, I'd be forced to write non-generic code:

Any paper in this area would have to engage with that.

HTH,

Arthur