[sigsev_251]

With all respect, please don't say nobody cares. There many people in the C community that want this but it's not easy to add a fat pointer to C after all these years. Though, there are people who are planning to work on this exact solution [1]. The best thing the rest of the ecosystem can do, is support them.

[1]: https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Non-own...

[WalterBright]

I've never gotten a positive response for it. I thank you for your interest on it and the reference, that's good!

BTW, it's simple to implement.

[sigsev_251]

(Just to be clear, I am not the author of the draft I posted in the parent comment, but it's the feature I want the most to be added in C2y. I was actually meaning of writting a proposal, but realized that I don't know a thing about compilers and language design.) I have examined many other ways one could add such functionality in C. I found that the most pleasant one is a combination of your syntax and some runtime operators to retrieve the length. As for the lack of implementation burden, I would send an email to thephd in your position. I think that having that comment coming from you would be really beneficial for the paper.

[teo_zero]

You don't need new runtime operators to retrieve the length. Once you remove the decay issue, you can use sizeof:

  sizeof(a)
  sizeof(a)/sizeof(a[0])

[sigsev_251]

I get what you mean and I'm not saying that not having extra operators is a dealbreaker that will make spans unusable. I just find it more pleasant/convenient for the following reasons: 1. Helps clarify intent 2. Makes teaching the feature easier, since it's name is closer to what the user wants to write. Also, rejecting pointers helps people not make mistakes. 3. Keeps sizeof consistent. The operator sizeof is supposed to return the size of the storage occupied by the object. A span is a pointer and some sizes (one could also design a span to be strided, meaning more integers to the mix), so sizeof could just return the size of that pointer ond the integers. Having sizeof be somewhat overloaded for spans could be surprising to nome people. But again, just having sizeof is fine

[pjmlp]

Even Denis himself has tried it [0], and failed to get enough people on WG14 to care.

What matters is if enough people in WG14 with voting rights care.

[0] - https://www.bell-labs.com/usr/dmr/www/vararray.pdf

[teo_zero]

Interesting, but how do you define a function that returns an array? Maybe:

  T f(args)[..] { body }

This would be hard to parse. Then what about:

  T[..] f(args) { body }

But if adding [] after T is allowed in function declaration, then why not for arrays as well:

  T[..] a;

[sigsev_251]

Very nice comment. This was a blocking point I fell onto too. There is another option, to not allow spans on the return channel, but I don't know how people who handle resources with lifetimes that exceed the function scope will take this. Just like you, I'm curious to see what how this will be solved.