  template <typename T>
  struct Slice {
      T* data = nullptr;
      size_t size = nullptr;

      T& operator[](size_t index) {
        if (index >= size) crash_the_program();
        return data[index];
      }
  };

If you're considering this extension, just use C++ and 5 lines of standard, portable, no-weird-annotations code instead.

▲ uecker 6 hours ago | parent | next [-]

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

▲

nananana9 5 hours ago | parent | next [-]

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

	▲	uecker 3 hours ago \| parent [-]
		Only statement expressions, but one can also implement this without them.

▲

fuhsnn 4 hours ago | parent | prev [-]

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

	▲	uecker 3 hours ago \| parent [-]
		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.

▲ zmodem 6 hours ago | parent | prev | next [-]

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

▲ pjmlp 6 hours ago | parent | prev | next [-]

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.

▲ nananana9 6 hours ago | parent | next [-]

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};
  }

	▲	pjmlp 6 hours ago \| parent [-]
		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.

▲ kitsune1 5 hours ago | parent | prev [-]

[dead]

▲ osmsucks 3 hours ago | parent | prev | next [-]

  size_t size = nullptr;

wat

▲ wat10000 6 hours ago | parent | prev | next [-]

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

▲ baq 6 hours ago | parent | prev [-]

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

▲

nananana9 6 hours ago | parent [-]

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.

	▲	yjftsjthsd-h 3 hours ago \| parent \| next [-]
		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.
	▲	zephen 6 hours ago \| parent \| prev [-]
		> 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.