<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Ryan Joseph <<a href="mailto:ryan@thealchemistguild.com">ryan@thealchemistguild.com</a>> schrieb am Mo., 18. März 2019, 00:50:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I just realized that typed constants exist and may need to be supported as constants for generics but I’ve never used them myself (not sure when they were introduced).<br>
<br>
First test gives an error so it makes me wonder if they’re buggy and should be allowed for generics. Should they?<br>
<br>
const<br>
  kInt: integer = 100;<br>
<br>
var<br>
  i: integer = kInt;    // ERROR: Illegal expression<br>
<br>
They don’t work for generics right now either because they appear as a load node and are not discernible from a variable. Not even sure how to know if a load node is a typed const or what these things really are.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">This is by design. Typed constants are essentially read only variables (in TP times they were writable by default, nowadays that can be controlled with $J) and thus they behave differently to untyped constants and can't be used as initializers for other constants or variables or as default parameters. </div><div dir="auto">That's also why I said to restrict generic const parameters to those for which a const node exists, cause those are true constants. </div><div dir="auto">So as for now you definitely don't need to support typed constants, they need to be rejected. We can always add support later, but we should first get a feel how generics with constants behave and how they're used before we open that can of worms. </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div><div dir="auto"></div></div>