Or just do it in C.

  #define span(T) struct span_##T { size_t len; T *data; }
  #define span_access(T, x, i) (*({              \
    span(T) *_v = (x);                           \
    auto _i = (i);                               \
    if (((size_t)_i) >= _v->len) abort();        \
    &_v->data[_i];                               \
  }))

https://godbolt.org/z/TvxseshGc

Still requires a gcc/clang specific extension (although this one I'd be very happy to see standardized)

Only statement expressions, but one can also implement this without them.

Still, please standardize them :).

I don't use much C but if you add them to the standard they'll probably trickle down to C++ compilers by 2045 and I'll have a good 10 years to use them before I retire.

You are not happy with immediately invoked lambda expressions?

Well, I'll take them over the nothing you're giving me :D

But in all seriousness, I want this:

  struct Result { int value; int err; };
  #define TRY(res) \
    ({ \
       Result _res = res; \
       if (failed(res)) return res; \
       res.value; \
    })
  Result f1(...) { ... }
  Result f2() {
     int res = TRY(f1(...)); // <<<<
     ...
     return success();
  }

Can't be done with lambdas since the macro needs to return out of the actual function, not the lambda. Pretty much rust question mark, but without rust, or zig "try" but without zig.

I see, thanks! There is general consensus that statement expressions should become part of ISO C, but some lack of time to get it done. I am not part of WG21 though, so can't say anything about C++.

The fact that pointer types can't be used with this pattern without typedef still seems kinda primitive to me.

You can use pointer types by using a typedef first, but I agree this not nice (I hope we will fix this in future C). But then, I think this is a minor inconvenience for having an otherwise working span type in C.

The extension is for hardening legacy C code without breaking ABI.

Even better, starting with C++26, and considered to be done with DR for previous versions, hardned runtimes now have a portable way to be configured across compilers, instead of each having their own approach.

However, you still need something like -fbounds-safety in C++, due to the copy-paste compatibility with C, and too many people writing Orthodox C++, C with Classes, Better C, kind of code, that we cannot get rid of.

I'm sure std::span is great, but I like mine better :)

I find it a bit hard to justify using the STL when a single <unordered_map> include costs 250ms compile time per compile unit.

The fact that I don't have to step through this in the debugger is also a bonus:

  template <size_t _Offset, size_t _Count = dynamic_extent>
  [[nodiscard]] _LIBCPP_HIDE_FROM_ABI constexpr auto subspan() const noexcept
      -> span<element_type, _Count != dynamic_extent ? _Count : _Extent - _Offset> {
    static_assert(_Offset <= _Extent, "span<T, N>::subspan<Offset, Count>(): Offset out of range");
    static_assert(_Count == dynamic_extent || _Count <= _Extent - _Offset,
                  "span<T, N>::subspan<Offset, Count>(): Offset + Count out of range");

    using _ReturnType = span<element_type, _Count != dynamic_extent ? _Count : _Extent - _Offset>;
    return _ReturnType{data() + _Offset, _Count == dynamic_extent ? size() - _Offset : _Count};
  }

Only if not able to do import std, or pre-compiled headers, and not using modern IDEs with "just my code" filters.

As someone that enjoys C++ since 1993, alongside other ecosystems, many pain points on using C++ complaints are self inflicted, by avoiding using modern tools.

Heck, C++ had nice .NET and Java alike frameworks, with bounds checking even, before those two systems came to exist, and nowadays all those frameworks are mostly gone with exception of Qt and C++ Builder ones, due to bias.

You should tell the LLVM folks, I guess they didn't know about this.

and if you write directly in assembly you don't even need a C++ compiler

That's an objectively correct statement, but I don't see how it makes sense as a response to my comment, as I'm advocating to use the more advanced feature-rich tool over the compiler-specific-hacks one.

> I don't see how it makes sense as a response to my comment

Your comment started out with "just."

As if there are never any compelling reasons to want to make existing C code better.

But instead of taking that as an opportunity to reflect on when various tools might be appropriate,

> as I'm advocating to use the more advanced feature-rich tool over the compiler-specific-hacks one.

You've simply doubled down.

If you're advocating switching languages, then there's no reason to stop at C++. It's more common to propose just converting the universe to Rust, but assembly also enjoys the possibility of being fairly easy to drop in on an existing C project.

  size_t size = nullptr;

wat