[fpc-pascal] Constants in generics

Sven Barth pascaldragon at googlemail.com
Tue Nov 6 17:19:43 CET 2018

Am Di., 6. Nov. 2018, 14:35 hat Ryan Joseph <ryan at thealchemistguild.com>

> > On Nov 6, 2018, at 8:21 PM, Sven Barth via fpc-pascal <
> fpc-pascal at lists.freepascal.org> wrote:
> >
> > 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.
> Can you give an example? There’s lots of ways generics can be used and I
> tested in only a few.

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.

> >
> > 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.
> 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.

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.
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.
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
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20181106/3d466638/attachment.html>

More information about the fpc-pascal mailing list