<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">Am Di., 6. Nov. 2018, 14:35 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"><br>
<br>
> On Nov 6, 2018, at 8:21 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>
> <br>
> First of I'm not a fan of adding support for constants, mainly because it will definitely not help parsing of inline specializations in mode Delphi which are going to be annoying enough already.<br>
<br>
Can you give an example? There’s lots of ways generics can be used and I tested in only a few.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Complex inline specializations containing, for example a multiplication with specializations on the left and the right side are currently not possible in mode Delphi. In addition to that Delphi allows overloads of generic types with variables and constants, so when the parser encounters "Bla<N" and has not yet encountered the ">" it does not know whether it needs to start a specialization or an expression. This is already annoying enough to solve with merely types, but if the right side of the "<" can also take constants for generics that gets downright proplematic. </div><div dir="auto"><br></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"><br>
>Â <br>
> That said: even if we do add it, then only if a generic constant parameter is designated as such with "const N" in the generic declaration instead of merely "N", so that the compiler does not assume it's a type. <br>
<br>
Why is this preferable? If you tried to pass a type for a constant in a specialization then you’d probably just get a type error which is easy to catch. Generics in FPC are already very verbose (“specialize" keyword is exhaustingly long) but adding “const†is at least a small cosmetic change in a single location.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Specialization is an expensive operation. When the compiler can already decide that "Something<SomeType, SomeOtherType>" can never be valid, because it's declared as "Something<T, const N>", then this is preferable. Otherwise the user might get some cryptic error message during the specialization, because "SomeOtherType" is used where only a constant can be used. </div><div dir="auto">Pascal is considered a type safe language and without forcing users to decorate such parameters as "const" you essentially allow users to mix types and constants. </div><div dir="auto">Not to mention that parsing the generic can already be done more correctly then it could be if the parameter is a typesym (which it would be right now). </div><div dir="auto">You can't do e.g. "const SomeOtherConst = ConstParam * Pi" that way as it would mean to ease up the compiler's restrictions for type checking even more. </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>