<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">Am Di., 8. Jan. 2019, 21:01 hat Ryan Joseph <<a href="mailto:ryan@thealchemistguild.com">ryan@thealchemistguild.com</a>> geschrieben:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I’ve made constants respect their proper definition now so we can do range checking but this broke some other things. For example there’s a range check error with static arrays now because “U” has a value of 0 so 0-1 = -1:<br>
<br>
type<br>
generic TList<const U:byte> = record<br>
list: array[0..U-1] of integer; // ERROR: high value < low value (0..-1)<br>
end;<br>
<br>
<br>
There’s a couple ways to resolve this:<br>
<br>
1) Add some extra flags to nodes/syms so “U-1” can be known to contain a generic parameter and errors can be ignored. That’s the most complicated solution and I wasn’t able to figure that out easily because flags need to be transferred in multiple locations.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This is the preferred solution as otherwise you'd also defeat the purpose of type safety and probably open another can of worms when constant parameters are used in more complex expressions. </div><div dir="auto"><br></div><div dir="auto">The symbols should already have sp_generic_param set (if not that should definitely be changed so that it matches the type symbols). Now you only need a way to differentiate whether the symbol is an undefined generic parameter or not. </div><div dir="auto">For type parameters it abuses the fact that the undefined defs of the parameters are children of the generic while the final types are never children of the generic. Maybe we can use something similar for the constants? </div><div dir="auto">If not we can always add some flag to tconstsym... </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div><div dir="auto"><div class="gmail_quote"></div></div></div>