This seems possibly a *little* too similar to the existing Interface type
in Object Pascal, however, I *would* really like to see some kind of
functionality that basically amounts to "has the same capabilities as
Interfaces and works on records and objects too, but does NOT require any
kind of heap
What you want is FPMake, not FPCMake. FPCMake is just a generator of GNU
makefiles. As Michael said elsewhere though, FPMake is an API designed
specifically for compiling FPC programs, basically. You write a program
using the API, put it in a file that should always be called "fpmake.pp",
and then
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.)
>
Al
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
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 y
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 mak
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 *al
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"
stateme
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"
> way,
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 differ
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
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.
>
There'
12 matches
Mail list logo
