[Issue 13228] Value range analysis for the length of slices

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13228

--- Comment #5 from Steven Schveighoffer <schveiguy at yahoo.com> ---
(In reply to bearophile_hugs from comment #4)
> (In reply to Steven Schveighoffer from comment #3)
> 
> > This ER is asking for flow analysis, which I think is not on the table.
> 
> According to Walter flow analysis is on the table for the future of D. But
> this ER doesn't want to ask for flow flow analysis (it's meant to work
> similarly to the current value range analysis. See also below). If this ER
> seems to ask for flow analysis then I have done a mistake in an example, or
> I have confused ideas :-)

I think your original example is not valid, as I have shown x can change before
main is called. But in general, I don't think main should be treated specially
by the compiler in terms of execution order.

Your example in comment 1 also suffers from the same issue.

The idea of avoiding runtime checks for array lengths when the length is known
at compile time is ok, but I think in general, this is not a large issue. It is
an infrequent case where the compiler knows the length of slices and can avoid
a runtime check.

One caveat to consider is that the result of a runtime call is defined by the
runtime, not the compiler. Although the spec defines what should happen, I'm
not certain it's worth eliding runtime checks for runtime code. For example,
there could be an error in the runtime that returns the wrong thing for new
int[2], and avoiding the runtime check will create other issues.

however, your 3rd example in comment 2 should be doable.

> > Value range analysis for expressions dies at the end of an expression.
> 
> This is not longer true, this compiles:
> 
> uint x = 10;
> void main() {
>     immutable uint y = x % 100;
>     ubyte z = y; // No errors here.
> }

I stand corrected, thanks for letting me know.

--