Hacker News new | past | comments | ask | show | jobs | submit login

> The proposal here is way too vague. And if you flesh it out, things start to fall apart

No, it's not, those ideas were implemented in practice in D and Rust, and there are no real issues with those. This feature could be easily implemented in C, there are no dependencies on features that C doesn't have.

> If nul-termination of strings is gone, does that mean that the fat pointers need to be three words long

No need to store the capacity. This is a slice, not a buffer. Go conflates those two for user's convenience, but this is not necessary, and in fact is waste of RAM - not an issue for Go, but it is an issue for C. For instance, `&str` in Rust is a pair of pointer to a string and its length and it works really well.

> If not, how do you manage to get string variable on the stack if its length might change? How does concatenation work such that you can avoid horrible performance (think Java's String vs. StringBuffer)?

Use your own slice buffer abstraction for that purpose. It can be implemented as a struct storing a slice and its capacity. Pass a pointer to slice buffer abstraction, if you want a function to be able to add elements to it. This is also how it works in Go, for that matter.

Slices don't define concatenation. This is C, not a high level programming language.

> Am I able to take the address of an element of an array?

Yes. `&a[3]`. It's still an array, it just knows its size.

> Will that be a fat pointer too?

No.

> How about a pointer to a sequence of elements?

Probably you could add some sort of a range access syntax. Say, something like `&a[1:3]`.

> Can I do arithmetic on these pointers?

I don't know whether pointer arithmetic should be allowed or not, but even if it shouldn't be, there is nothing to stop you from doing `&a[4]` as a replacement for `a + 4`.

> How would you write Quicksort? Heapsort?

The same way you would with a regular array. Think of it as a struct storing an array pointer and its length. If you prefer to working with pair of start/end pointers instead of pair of start and array size, then note that `end - start` is array length, so getting an end pointer is trivial.




> No, it's not, those ideas were implemented in practice in D and Rust, and there are no real issues with those.

Even older than that, those features already existed in NEWP, Mesa and Modula-2, just to pick some examples back when C was being designed still.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: