<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Ben Grasset via fpc-pascal <<a href="mailto:fpc-pascal@lists.freepascal.org">fpc-pascal@lists.freepascal.org</a>> schrieb am Mi., 6. Nov. 2019, 04:49:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, Nov 5, 2019 at 5:24 PM Sven Barth via fpc-pascal <<a href="mailto:fpc-pascal@lists.freepascal.org" target="_blank" rel="noreferrer">fpc-pascal@lists.freepascal.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">Does this really work? Cause the compiler should nevertheless typecheck the code in the other branch and thus without casts that shouldn't compile. </div><div dir="auto">Also if it should indeed work, it would also work without the if-expression, but with an if-statement.</div></div></blockquote><div><br></div><div>Hm, it actually doesn't quite for that particular example, testing it for real. It definitely did for a few other generic things I experimented with though (that were impossible otherwise.) I'll see if I can find the source files anywhere.</div><div><br></div><div>Why would it work the same way as a normal if statement, though? Isn't the non-evaluation of the false branch pretty much the only point of the ternary "form"? E.G. you'd specifically use it when you had two branches that you knew would never *both* be compilable.</div><div>You'd be able to do the same thing with an {$IFDEF}, for example, if {$IFDEFS} specifically carried through across generic specializations.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">A normal if-statements has the same non-evaluation. However that it might not be evaluated does not mean that it is not type checked. Especially as the type of the expression is taken from the if-branch. Imagine this:</div><div dir="auto"><br></div><div dir="auto">=== code begin ===</div><div dir="auto"><br></div><div dir="auto">SomeLongint := if SomethingFalse then SomeOtherLongint else SomeString;</div><div dir="auto"><br></div><div dir="auto">=== code end ===</div><div dir="auto"><br></div><div dir="auto">The if-branch is obviously not taken here. But nevertheless the type of the whole condition is LongInt, because the type of the if-branch is LongInt. Thus there will be a type error in the else-branch even before the compiler determines that the if-condition is constant and False. </div><div dir="auto"><br></div><div dir="auto">And the if-expression behaves like an if-clause, because the compiler transforms it as such. The above example becomes (in the node tree) essentially the following (general case without further optimizations):</div><div dir="auto"><br></div><div dir="auto">=== code begin ===</div><div dir="auto"><br></div><div dir="auto"><div dir="auto">if SomethingFalse then</div><div dir="auto">  tmpLongInt := SomeOtherLongint</div><div dir="auto">else</div><div dir="auto">  tmpLongInt := SomeString;</div><div dir="auto"><span style="font-family:sans-serif">SomeLongint := tmpLongInt;</span><br></div></div><div dir="auto"><br></div><div dir="auto">===code end ===</div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>