<div dir="ltr"><div dir="ltr">On Thu, Nov 7, 2019 at 3:03 AM Sven Barth via fpc-pascal <<a href="mailto:fpc-pascal@lists.freepascal.org">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 bgcolor="#FFFFFF">
    <blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div></div>
        </div>
      </div>
    </blockquote>
    If there is no type checking, then it is *not* verified by the
    compiler.</div></blockquote><div><br></div><div>Perhaps "no type checking" was not the write way to put it. A better way to describe it might be:</div><div><br></div><div>Since the compiler *always* knows exactly which type a generic type constraint currently amounts to, it is clearly capable of properly choosing specific code paths based on that, if given some kind of constant-evaluatable boolean condition that is specifically based on TTypeKind.</div><div><br></div><div>In general, it's *exactly* the same concept as something like using SizeOf in an {$IF} / {$ELSEIF} directive pair (where the compiler does indeed completely ignore everything in the "false" section):</div><div><br></div><div>program Example;<br><br>begin</div><div>  // You can in fact put stuff that isn't even close to valid code in whichever block is false for you, below.<br>  {$IF SizeOf(Pointer) = 4}<br>    

WriteLn('The size of a pointer is 4 bytes.');

<br>  {$ELSEIF SizeOf(Pointer) = 8}<br>    WriteLn('The size of a pointer is 8 bytes.');<br>  {$ENDIF}<br>end.<br></div><div><br></div><div>Not that it has to do precisely the same thing for a hypothetical TTypeKind-based choice. </div><div><br></div><div>E.G. it could still do the full checking, as the only thing that really matters is that it does not actively raise error messages only relevant for Integer under code blocks only entered for tkFloat.</div></div></div>