uecker

You are telling me what my point was?

Maybe, but also irrelevant to the discussion because whether you write mat[b * A + a] by hand or mat[b][a] and let the compiler frontend expand then makes no difference to the optimizer.

Well, you give the explanation yourself: The size for the outermost array is not always needed, and then C allows it to be omitted. But my recommendation is to always give the size and then everything…

The point is much easier to propagate information (and not accidentally lose it) than to deduplicate after specialiation, so I do not agree that this is only of theoretical relevance. I agree that mon…

But since you mentioned it, the interoperation of vec/span and arrays is also really nice in my opinion: https://godbolt.org/z/nYe48jh5d …

The example shown does not use vec from my experimental library. But yes, I was thinking about making a custom-allocator version of vec.

It is a struggle though to get the improvements through the committee. Especially the C++ folks from the Clang side fight very hard against it, this is - for example - why we not have forward declarat…

I don't know. I see people increasingly make use of it. The problem was that in the past compilers ignored this completely, so there was simply no point. Nowadays GCC uses it for warning (the le…

"breaks completely" I rather would say it works nicely in auto-generating the complex indexing operation for n-dimensional arrays which makes it a lot more convenient and less error-prone to…

We are working towards this though and a lot of this already works: https://godbolt.org/z/EP3cP3qGs …

No, I don't think this is true and just the usual nonsense used as justification. Some people continue to develop X, so I hope this is sufficient that I can continue to avoid Wayland.

It can always specialize where you could do monomorphization.

The vtable can be removed in all cases where you specialize by monomorphization, so the overhead compared to it is not really inherent. Type-erasure can be undone by specialization. In contrast, mono…

What inherent overhead does type-erasure have? The optimizer can always specialize just like for monomorphization. The difference is that it does not have to do this. Monomorphization specializes eve…

Well, one could consider Mozilla's management of firefox to be outrageous, but then, Google pays, so what to expect?

It would also, but nobody cares enough because qsort is already fast enough for most things, and if you cared it is simply enough to do yourself. Are you doubting that C compilers can devirtualize fu…

I remember the story, but it was considered outrageous for a reason.

Some of Rust's problems may be fixable, but they are not being fixed at the moment and with something as complex as Rust, this is unlikely. I do not think monomorphization is an implementation de…

Yes, attacker controlled size without limit is bad (and this is also true for heap allocations). For VLAs there is -Wvla-larger-than that can be used to ensure there is a hard limit. To understand the…

Why do you think they are dangerous?

Not sure what numbers you are talking about. If you use qsort from the C library the comparison function will not be inlined, but if you provide your own, this is no problem.

Assuming you mean the standard does not provide features for numa and simd? It doesn't necessarily have to. I think it is not surprising that you seem always bewildered that people still use C (a…

Ah, the "what is not standardized does not exist" argument again.

Yes, a static_cast would be safe, but then most C++ seems to use a C-style cast because it is less clunky and then is less safe than the corresponding C code. The issue is not that the downcast is u…

It doesn't have to be ISO, but some organization which follows some official rules and not some entity dependent on industry donations.

They make sense but reduce type safety, because once you add the cast the case might hide some real typing issue. I sympathize with the idea that the down-cast should be explicit though.

More complex != stronger. A weak type system would imply that the type systems forgives type mismatches. C had this before it imported prototypes from C++ where you could call a function without dec…

The correct choice IMHO is type-erasure. It does not necessarily have overhead, because optimizers can specialize or devirtualize. Of course, this my depend on how you implement your language, but in …

What IMHO Rust does not get right and why I do not use it: long compilation times, high complexity, its syntax, polymorphism based on monomorphization, the requirement for many dependencies to get any…

It has no fundamental architectural advantages. That some newer features are now only implemented on Wayland makes the situation worse.