There's a time and place for everything. Regarding the time, it is and has been the time for this since lisp emanated. But C is not the place, IMO. I don't want to be left to wonder about sizeof(anything) in C.
"Lisp Programmers know the value of everything and the cost of nothing."
C programmers ought to know the cost and sizeof everything...
I hope the committee sees it like this as well.
I also believe the feature (auto) makes sense for C++ with its verbose and lengthy types nobody but your compiler cares about (say, e.g., multimap::equal_range). For C? Get out of here..
this passes, and suddenly zig becomes a whole lot more interesting ;)
(but zig also has type inference you say? Well, it's a consistent proposition, and not a tacked-on "feature".)
With some slight tweaking variable modified types are the simplest and cleanest way forward to supporting arrays/slices as function parameters.
void foo(size_t n, char buf[n]) {
size_t m = sizeof buf;
}
In a saner world n and m should be equal, but in a cruel twist it doesn't do what you'd expect. I don't understand why the committee crippled the semantics here when adding VLAs and variable modified types. Never too late to fix things, though.
The reason it doesn't work despite being syntactically correct is because the standard goes out of its way to declare that, despite appearances, buf still behaves as if declared as `char *buf`. Thus sizeof just evaluates to the size of a pointer.
I think the original intent of the variably modified parameter syntax was merely to support optimization--a compiler could hypothetically prefetch n elements. Whether or why they didn't care to consider the potential security and robustness benefits of making the semantics behave like automatic storage VLAs, I have no idea. But over the years I've seen multiple proposals to rehabilitate the semantics.
> I also believe the feature (auto) makes sense for C++ with its verbose and lengthy types nobody but your compiler cares about (say, e.g., multimap::equal_range). For C? Get out of here..
It's more than convenience. auto is effectively mandatory in many cases where the return type of templates/functions is private to the implementation (lambdas being the most common example, but libraries like hana make extensive use of such private types).
"Lisp Programmers know the value of everything and the cost of nothing."
C programmers ought to know the cost and sizeof everything...
I hope the committee sees it like this as well.
I also believe the feature (auto) makes sense for C++ with its verbose and lengthy types nobody but your compiler cares about (say, e.g., multimap::equal_range). For C? Get out of here..
this passes, and suddenly zig becomes a whole lot more interesting ;) (but zig also has type inference you say? Well, it's a consistent proposition, and not a tacked-on "feature".)