Re: [fpc-pascal] Generic type conflicts

Ryan Joseph via fpc-pascal schrieb am So., 10. Nov. 2019, 02:11: > > > > On Nov 7, 2019, at 12:28 PM, Ben Grasset via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > {$IF GetTypeKind(T) in [tkInteger, tkInt64, tkQWord]} > > Result := A div B > > {$ELSEIF GetTypeKind(T) =

Re: [fpc-pascal] Generic type conflicts

> On Nov 7, 2019, at 12:28 PM, Ben Grasset via fpc-pascal > wrote: > > {$IF GetTypeKind(T) in [tkInteger, tkInt64, tkQWord]} > Result := A div B > {$ELSEIF GetTypeKind(T) = tkFloat} > Result := A / B > {$ELSE} > Result := Default(T); > {$ENDIF} This is what I hinted in my

Re: [fpc-pascal] Generic type conflicts

Am 02.11.2019 um 15:55 schrieb Ryan Joseph via fpc-pascal: I've wanted to make a generic version of a vector for a while but I always give up because it seems not very possible. It's probably not even a great idea because many methods don't translate between float and integer but I wanted to

Re: [fpc-pascal] Generic type conflicts

On Fri, Nov 8, 2019 at 11:18 AM Ben Grasset wrote: > I know what you mean, and I'm aware, but you actually kind of can to the > fairly straightforward extent that I'm concerned about with Ryan's patch > (i.e. simply passing constant results as constraints rather than function > parameters.) >

Re: [fpc-pascal] Generic type conflicts

On 08/11/2019 17:18, Ben Grasset via fpc-pascal wrote: > On Fri, Nov 8, 2019 at 11:04 AM Jonas Maebe > wrote: > > You can't. It's the main difference between C++ templates, which is a > Turing-complete programming language, and generics, which is simply a >

Re: [fpc-pascal] Generic type conflicts

On Fri, Nov 8, 2019 at 11:04 AM Jonas Maebe wrote: > You can't. It's the main difference between C++ templates, which is a > Turing-complete programming language, and generics, which is simply a > parametrising mechanic. > I know what you mean, and I'm aware, but you actually kind of can to the

Re: [fpc-pascal] Generic type conflicts

On 08/11/2019 17:02, Ben Grasset via fpc-pascal wrote: > The original C++ version used "constexpr" template parameters to > determine at compile time whether or not the user-provided comparison > function was one for which it should use the "branchless" version of its > code for item partitioning

Re: [fpc-pascal] Generic type conflicts

On Fri, Nov 8, 2019 at 1:33 AM Michael Van Canneyt wrote: > As an aside: > In my opinion (keep in mind I am not a big fan of generics) the above code > would be a prime example where one should not be using generics, but > simple overloads. > If you need to use GetTypeKind in a generic, I think

Re: [fpc-pascal] Generic type conflicts

On Thu, 7 Nov 2019, Ben Grasset via fpc-pascal wrote: On Thu, Nov 7, 2019 at 10:23 AM Michael Van Canneyt wrote: If I understood Sven's example correct, then the compiler does exactly this already. It does in the sense of *code generation* for things that are specifically compiler

Re: [fpc-pascal] Generic type conflicts

On Thu, Nov 7, 2019 at 10:23 AM Michael Van Canneyt wrote: > If I understood Sven's example correct, then the compiler does exactly this > already. > It does in the sense of *code generation* for things that are specifically compiler intrinsics (which I was aware of), but not in a sense that

Re: [fpc-pascal] Generic type conflicts

Michael Van Canneyt schrieb am Do., 7. Nov. 2019, 16:23: > > > On Thu, 7 Nov 2019, Ben Grasset via fpc-pascal wrote: > > > On Thu, Nov 7, 2019 at 3:03 AM Sven Barth via fpc-pascal < > > fpc-pascal@lists.freepascal.org> wrote: > > > >> If there is no type checking, then it is *not* verified by

Re: [fpc-pascal] Generic type conflicts

On Thu, 7 Nov 2019, Ben Grasset via fpc-pascal wrote: On Thu, Nov 7, 2019 at 3:03 AM Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: If there is no type checking, then it is *not* verified by the compiler. Perhaps "no type checking" was not the write way to put it. A

Re: [fpc-pascal] Generic type conflicts

On Thu, Nov 7, 2019 at 3:03 AM Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > If there is no type checking, then it is *not* verified by the compiler. > Perhaps "no type checking" was not the write way to put it. A better way to describe it might be: Since the compiler

Re: [fpc-pascal] Generic type conflicts

Am 07.11.2019 um 01:33 schrieb Ben Grasset via fpc-pascal: On Wed, Nov 6, 2019 at 12:44 PM Sven Barth via fpc-pascal > wrote: Pascal has a strong type safety, thus something like the if-expression won't be used/allowed to weaken that. If

Re: [fpc-pascal] Generic type conflicts

Am 07.11.2019 um 01:42 schrieb Ben Grasset via fpc-pascal: On Wed, Nov 6, 2019 at 7:33 PM Ben Grasset > wrote: Encouraging typecasting (which cares only about the sizes of the types involved, nothing else) at the programmer level is far more error-prone

Re: [fpc-pascal] Generic type conflicts

On Wed, Nov 6, 2019 at 7:33 PM Ben Grasset wrote: > Encouraging typecasting (which cares only about the sizes of the types > involved, nothing else) at the programmer level is far more error-prone in > a variety of ways. > Also: it's slower in many cases, because it tends to involve "if"

Re: [fpc-pascal] Generic type conflicts

On Wed, Nov 6, 2019 at 12:44 PM Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > Pascal has a strong type safety, thus something like the if-expression > won't be used/allowed to weaken that. > > If that means that some things can't be implemented in generics the "easy" >

Re: [fpc-pascal] Generic type conflicts

Ben Grasset via fpc-pascal schrieb am Mi., 6. Nov. 2019, 15:43: > On Wed, Nov 6, 2019 at 2:01 AM Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > >> A normal if-statements has the same non-evaluation. >> > > Not in the way I meant, though. > > Like, I thought the

Re: [fpc-pascal] Generic type conflicts

On Wed, Nov 6, 2019 at 2:01 AM Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > A normal if-statements has the same non-evaluation. > Not in the way I meant, though. Like, I thought the difference between "normal if" and "ternary if" was supposed to be the same as the

Re: [fpc-pascal] Generic type conflicts

Ben Grasset via fpc-pascal schrieb am Mi., 6. Nov. 2019, 04:49: > On Tue, Nov 5, 2019 at 5:24 PM Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > >> Does this really work? Cause the compiler should nevertheless typecheck >> the code in the other branch and thus without

Re: [fpc-pascal] Generic type conflicts

On Tue, Nov 5, 2019 at 5:24 PM Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > Does this really work? Cause the compiler should nevertheless typecheck > the code in the other branch and thus without casts that shouldn't compile. > Also if it should indeed work, it would also

Re: [fpc-pascal] Generic type conflicts

Ben Grasset via fpc-pascal schrieb am Di., 5. Nov. 2019, 19:11: > On Sat, Nov 2, 2019 at 11:51 AM Ryan Joseph via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > >> Are there any solutions for this currently? I feel like generics need to >> support some compiler directives so different

Re: [fpc-pascal] Generic type conflicts

On Sat, Nov 2, 2019 at 11:51 AM Ryan Joseph via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > Are there any solutions for this currently? I feel like generics need to > support some compiler directives so different blocks of code can specialize > different depending on the type. >

Re: [fpc-pascal] Generic type conflicts

> On Nov 2, 2019, at 11:06 AM, Cyrax via fpc-pascal > wrote: > > You need to do a explicit typecasting. > > ... > fac:=Sqrt(Sqr(TScalar(x)) + Sqr(TScalar(y))); > ... > fac:=1.0/TScalar(fac); Doesn't work. Try running the example. Regards, Ryan Joseph

Re: [fpc-pascal] Generic type conflicts

On 02/11/2019 16:55, Ryan Joseph via fpc-pascal wrote: I've wanted to make a generic version of a vector for a while but I always give up because it seems not very possible. It's probably not even a great idea because many methods don't translate between float and integer but I wanted to

[fpc-pascal] Generic type conflicts

I've wanted to make a generic version of a vector for a while but I always give up because it seems not very possible. It's probably not even a great idea because many methods don't translate between float and integer but I wanted to prevent other code duplication if possible. Here's an