Re: [fpc-pascal] Feature announcement: default namespaces

Cool I guess. Kind of seems not very important at all though. FPC lacks compatibility with current Delphi in various other far more significant areas... Virus-free. www.avast.com

Re: [fpc-pascal] Operator overload bug

By looks like I meant, "is", not sure why I wrote that. (I'm Akira1364, by the way.) On Mon, Jul 30, 2018 at 6:11 PM, Ben Grasset wrote: > If you don't have an SVN patch utility handy you could probably just look > at it and apply it to your sources yourself. The final version l

Re: [fpc-pascal] Operator overload bug

If you don't have an SVN patch utility handy you could probably just look at it and apply it to your sources yourself. The final version looks like it's just two lines changed in a single file. On Mon, Jul 30, 2018 at 11:29 AM, Ryan Joseph wrote: > > > > On Jul 28, 2018, at 8:38 AM, John Doe >

Re: [fpc-pascal] Operator overload bug

It's still open by my view, with "new" status: https://bugs.freepascal.org/view.php?id=34021 On Tue, Jul 31, 2018 at 11:47 AM, Ryan Joseph wrote: > > > > On Jul 30, 2018, at 4:11 PM, Ben Grasset wrote: > > > > If you don't have an SVN patch utility ha

Re: [fpc-pascal] Operator overload bug

On Sat, Aug 4, 2018 at 10:38 AM, Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > On 28.07.2018 16:38, John Doe wrote: > > On Mon, Jul 23, 2018 at 1:49 PM, Sven Barth via fpc-pascal > > > > wrote: > > > > Ryan Joseph >

Re: [fpc-pascal] Syntax changes suggestions

How is auto more "ugly" than literally any other modifier in the entire language? They're all just english words, of varying length. Also building features on top of a language will always result in worse performance than having them be a part of it. On Wed, Jul 25, 2018 at 10:05 AM, R0b0t1

Re: [fpc-pascal] Syntax changes suggestions

> For high performance in a game engine you should not allocate/deallocate memory in the game loop at all (can be done, have done it*, so no arguing there). This is a massive oversimplification. Many *modern* game engines do not even have the kind of loop you're thinking of. > Outside the game

Re: [fpc-pascal] Syntax changes suggestions

Yawn, more F.U.D. On Wed, Jul 18, 2018 at 9:20 PM, Reimar Grabowski wrote: > On Wed, 18 Jul 2018 16:12:41 -0600 > Ryan Joseph wrote: > > > Personally for my taste I would like to just add a little keyword to the > end of the variable so I don’t have to worry about it later. > > 1) little,

Re: [fpc-pascal] Syntax changes suggestions

Well, the array TFPGList uses for storage would still be allocated on the heap in any case no matter what... On Wed, Jul 18, 2018 at 3:10 PM, Ryan Joseph wrote: > > > > On Jul 18, 2018, at 12:47 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > A point against

Re: [fpc-pascal] Syntax changes suggestions

Ironically, type safety is a good argument for the further development of various generics related things. Yet unfortunately I don't think anyone is going to stop using the Contnrs unit in new code anytime soon... ___ fpc-pascal maillist -

Re: [fpc-pascal] Syntax changes suggestions

The "I might have to read code I don't like" argument people seem to keep resorting to comes off as rather childish, frankly. It's entirely subjective and specific to each person. For example, does *anyone *actually think the strange "lowercase everything" capitalization style the compiler uses

Re: [fpc-pascal] Syntax changes suggestions

July 2018 23:30:19 Ben Grasset wrote: > > > > For example, does *anyone *actually think the strange "lowercase > > everything" capitalization style the compiler uses is "readable" > nowadays? > > Yes. > > Martin > ___

Re: [fpc-pascal] Syntax changes suggestions

If a feature works as intended and is useful (which is all that matters), how is it "blind copying"? On Thu, Jul 19, 2018 at 7:25 AM, Marco van de Voort wrote: > > In our previous episode, Ryan Joseph said: > > > > That?s pretty disheartening honestly. So there was a useful feature users > >

Re: [fpc-pascal] Syntax changes suggestions

On Fri, Jul 20, 2018 at 1:20 AM, Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > > Because a feature might change the language in a way that's not in the > spirit of the language. Look at how Delphi implemented attributes: they're > declared in front of the types, fields,

Re: [fpc-pascal] Syntax changes suggestions

Isn't Delphi compatibility a major ongoing goal of both FPC and Lazarus, though? On Fri, Jul 20, 2018 at 10:01 AM, R0b0t1 wrote: > On Fri, Jul 20, 2018 at 12:20 AM, Sven Barth via fpc-pascal > wrote: > > Am 20.07.2018 um 00:53 schrieb Ben Grasset: > >> > >>

Re: [fpc-pascal] Operator overload bug

Also, one other thing: you should *really* be specifying the right-hand-side array parameter as "const" there. If you don't, it will be copied in its entirety instead of being passed by reference. Basically just always pass everything as "const" (or "constref" if it's specifically a record)

Re: [fpc-pascal] Operator overload bug

e type: > > > > TIntArray = array of Integer; > > > > operator + (left: TMyClass; right: TIntArray): TMyClass; overload; > > > > and with retyping it works: > > > > c := c + TIntArray([1, 2, 3]); > > > > V. > > > > > > _

Re: [fpc-pascal] Operator overload bug

I'd say it's a bug in the sense that the compiler assumes something starting with "[" and ending with "]" can only possibly be a set in that context. On Sun, Jul 22, 2018 at 12:10 PM, Ryan Joseph wrote: > I mentioned this as an aside a while ago but I don’t remember getting a > response so I’d

Re: [fpc-pascal] Syntax changes suggestions

They observably *are* good though, now that they've been implemented, especially in combination with management operators. These are features that objectively make FPC better. I'm unsure what the original concern could have even possibly been, other than some vague notion of "well, records didn't

Re: [fpc-pascal] Proposal for new Free Pascal logo

I'm not at all getting why people think it's "kitten-like." Have you guys ever actually seen a kitten? This logo looks like a cheetah, as it's presumably supposed to. And a much better/more tasteful cheetah than that ancient, annoying "running" GIF at the top of all the Free Pascal websites

Re: [fpc-pascal] Indexing into records using [] property

If the absence of dereferencing is the most important thing to you, you could do something like this: program Example; {$mode ObjFPC}{$H+} {$modeswitch AdvancedRecords} type TVec2 = record X, Y: Integer; end; TVec2Array = array of TVec2; TVecArray = record strict private

Re: [fpc-pascal] Default properties first draft

AFAIK you need to submit a ".patch" file with your changes against the most recent trunk revision to the bugtracker (with the category set to "patch", obviously.) I doubt it'll get considered seriously or looked at at all otherwise. For what it's worth, I did do a checkout of your branch and then

Re: [fpc-pascal] Constants in generics

On Thu, Nov 8, 2018 at 11:50 PM Ryan Joseph wrote: > Question: should other consts besides integers be allowed? I don’t think > it makes sense personally to use strings, floats or sets but maybe I’m > wrong. > As a daily FPC user there's nothing I find more annoying than compiler restrictions

Re: [fpc-pascal] Default record const values

On Sat, Nov 10, 2018 at 9:03 PM Ryan Joseph wrote: > Not sure how default fields in generics help here. I just thought it would > be nice if FPC supported this so we can init records at compile time > easier. I’d prefer default struct fields like C++ has but typed const > defaults would be an

Re: [fpc-pascal] Default record const values

On Sat, Nov 10, 2018 at 4:06 AM Ryan Joseph wrote: > Should’t this work? This would be a good way to set default record values > but it doesn’t seem to be supported. Personally I think the answer here is keep working on your new/alternate implementation of default field functionality! It's a

Re: [fpc-pascal] Constants in generics

Just wanted to say, I've been playing around with Ryan's github branch that contains this functionality and I'm loving it! It really opens up a ton of interesting possibilities in general, and also a lot of potential for optimization via constant folding for generic containers that wasn't really

Re: [fpc-pascal] Constants in generics

On Sun, Jan 6, 2019 at 4:23 PM Ryan Joseph wrote: > This is exactly the reason I added the feature, there’s no way to extend > static arrays otherwise! Beyond this one thing I have no idea what to use > them for. ;) > I've got a bunch of stuff in mind actually that I'm waiting on the "final"

Re: [fpc-pascal] Default properties wiki

Nice! Very thorough. I think most of these are very useful. On Tue, Dec 18, 2018 at 2:32 AM Ryan Joseph wrote: > I decided to make a wiki going over all the details of default properties > which I’ve covered so far, including various usage examples. There’s some > questionable stuff in here and

Re: [fpc-pascal] Constants in generics

You still have two C-style operator += instances in pgenutil.pas FYI, that don't compile with the default settings. On Sun, Jan 6, 2019 at 8:36 PM Ryan Joseph wrote: > I updated the github with the requested changes. Is that everything? I’ll > submit a patch if so. > >

Re: [fpc-pascal] Constants in generics

Also, there's: pgenutil.pas(158,28) Warning: Class types "tenumdef" and "torddef" are not related which breaks compilation because the compiler is built with -sew turned on if you do it through the normal makefiles. I think you need tests before you do a patch, also? (Unless you already have

Re: [fpc-pascal] mode switch madness

I dunno about setting them globally, but generally I do find modeswitches rather annoying, as the combination of features is pretty arbitrary, and they mostly just *disallow* things that couldn't break the code of people who weren't using those features to begin with if they were allowed. E.G, I

Re: [fpc-pascal] not inlined?

On Wed, Jun 19, 2019 at 2:36 PM Ryan Joseph wrote: > The method TDictionary.IsSet is not able to be inlined but why not? What > are the rules to inlining in FPC? I know calling inherited is not possible > (makes sense) but I often get this warning and I don’t always understand > why. > It

Re: [fpc-pascal] not inlined?

On Wed, Jun 19, 2019 at 3:40 PM Ryan Joseph wrote: > What are the rules with he calling context? I didn’t even know that was a > factor! I’ll have to look to get some examples. > Basically, if you're calling a function marked inline from another function, the implementation of the function to

Re: [fpc-pascal] Virtual object methods

On Thu, Jun 27, 2019 at 5:57 PM Ryan Joseph wrote: > > Heap allocate how so? Calling the constructor seems to fix this and puts > the VMT table on the stack (I think anyways). Btw I’m doing this > specifically as testing for a possible “advancedobjects” mode switch and > the only reason to use

Re: [fpc-pascal] Virtual object methods

On Thu, Jun 27, 2019 at 4:17 PM Ryan Joseph wrote: > Why do I get a runtime error with this? > If you specifically need inheritance (combined with virtual methods) you should probably just use classes, because doing it with objects will require heap allocation regardless.

Re: [fpc-pascal] String conversions

On Wed, Jun 26, 2019 at 5:48 AM Michael Van Canneyt wrote: > I second that. > > Michael. > I think Ryan probably meant his own custom types. And certainly, you can do some interesting stuff with operator overloading that mostly avoids the normal AnsiString overhead. Here's an example.

Re: [fpc-pascal] String conversions

On Wed, Jun 26, 2019 at 3:28 PM Ben Grasset wrote: > I think Ryan probably meant his own custom types. And certainly, you can > do some interesting stuff with operator overloading that mostly avoids the > normal AnsiString overhead. Here's an example. > <https://godbolt.o

Re: [fpc-pascal] String conversions

On Wed, Jun 26, 2019 at 5:36 PM Ryan Joseph wrote: > Yes indeed. FPC already has an overwhelming amount of string types. As I > said though a SetCapacity option for growing would be nice (for dynamic > arrays also) because += is such a common operation. As it stands I often > don’t use dynamic

Re: [fpc-pascal] class operator enumerator

Seems like it's mixed up in some way with the FPC-style enumerator operator, so the "class" version is recognized but not actually implemented currently or something. The normal way for classes/records/objects is to implement a GetEnumerator function, anyways. Here's an expanded-on version of

Re: [fpc-pascal] Tests results of several pascal based JSON parsers

On Fri, Aug 30, 2019 at 5:16 AM Michael Van Canneyt wrote: > The shootout benchmarks for example are dismally coded for FPC with as a > result that they perform badly. > Not all of them! At least, not anymore:

Re: [fpc-pascal] [Lazarus] Tests results of several pascal based JSON parsers

On Sat, Aug 31, 2019 at 9:40 AM Anthony Walter wrote: > > Could you include https://github.com/BeRo1985/pasjson in the comparison? > > Sure. I also have a few other people have requested. I will also list the > license of each in the first table. > Note that I'm not sure if it's FPC-compatible,

Re: [fpc-pascal] for-in loop cast

On Thu, Sep 26, 2019 at 11:37 AM Ryan Joseph wrote: > Question I’ve always had. Why do I need to cast “value” to “pointer" > otherwise I get: Incompatible types: got "Pointer" expected “TObject” > error?. I don’t find this very helpful and it doesn’t really make sense > even. > Well,

Re: [fpc-pascal] for-in loop cast

On Thu, Sep 26, 2019 at 11:59 AM Ben Grasset wrote: > -snip- > I meant to change the last part of the revised code example to: for value in list do because obviously the pointer cast is no longer necessary in that case. ___ fpc-pascal ma

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

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

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

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

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

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 tend

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] fpcmake packaging

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

Re: [fpc-pascal] Traits Proposal

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