Can I propose we add a new $modeswitch-all (or some equivalent) that globally sets modeswitch in all subsequent units? I’m thinking about how messy this list is getting after these new mode switches are added and that the problem is only going to grow. I really like how FPC lets us opt into specific features but it’s becoming unruly and tedious.

Even if this isn’t the best solution anything resembling a manager or wrangler would be good.

program test;
{$modeswitch-all autoderef}
{$modeswitch-all advancedrecords}
{$modeswitch-all typehelpers}
{$modeswitch-all multihelpers}
{$modeswitch-all implicitfunctionspecialization}

...

Regards,
Ryan Joseph

That would break with the rule that directives do not cross unit boundaries. It has far-reaching consequences.

Better introduce a command-line switch to set mode switches.

Michael.

I would use something like {$include mysettings.inc} .

But is it maybe time we reconsider this or add an extension? It’s really getting out of hand now.

Problem with compiler switches is that they’re decoupled from the program itself and not documented in the actual programs source code. Honestly I’d prefer all compiler switches be stored in the program file so we didn’t have distribute extra files that contain command line arguments.

Regards,
Ryan Joseph

I really don't think we should reconsider this.
Locality is a good rule. It keeps things predictable.

Maybe you're just using the wrong combination of options ? I don't have a single project where I have to use modeswitches.

Problem with compiler switches is that they’re decoupled from the program itself and not documented in the actual programs source code. Honestly I’d prefer all compiler switches be stored in the program file so we didn’t have distribute extra files that contain command line arguments.

What happens if you have a third-party unit that is aversely affected by the settings in your program ? I don't think this is a good idea.

So, I'd prefer to keep things local.

You can do a

{$i mysettings.inc}

if you really need that many options. The effect is the same.

Michael.

Joao Schuler wrote

I would use something like {$include mysettings.inc} .

Exactly.

Michael.

Ryan Joseph schrieb am Fr., 12. Apr. 2019,
16:37:

Let me think... Nope. Not the time.

Regards,
Sven

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 sincerely doubt that anybody has *ever* thought, "man, I sure am glad that {$mode ObjFPC} does not allowed advanced records. It would be specifically bad if it did!" because it just doesn't matter if they weren't using advanced records to start with. It's just a lot of minor rules that nobody can really explain but that tend to add up in relatively annoying ways.

Ben Grasset wrote

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.

It helps a lot to force a certain programming style.

Someone said:

"You can do a {$i mysettings.inc}"

I give that a +1

On Apr 13, 2019, at 10:07 PM, Ben Grasset wrote: E.G, I sincerely doubt that anybody has *ever* thought, "man, I sure am glad that {$mode ObjFPC} does not allowed advanced records. It would be specifically bad if it did!" because it just doesn't matter if they weren't using advanced records to start with. It's just a lot of minor rules that nobody can really explain but that tend to add up in relatively annoying ways.

I like what Jonas did for the ObjC mode switch where he named them with versions. Maybe a {$mode objfpc2} one day.

Regards,
Ryan Joseph

That was because Apple did the same with the Objective-C language: https://en.wikipedia.org/wiki/Objective-C#Objective-C_2.0 :)

Jonas

The thing is that we do try to be backwards compatible and thus rather conservative with mode ObjFPC. E.g. the following code compiles without the modeswitch set, but not with:

=== code begin ===

program tmw;
{$mode objfpc}
type
   TTest = record
     private: LongInt;
     public: LongInt;
     protected: LongInt;
     strict: Longint;
   end;
begin
end.

=== code end ===

This hasn't always been done optimally in the past, e.g. when I added class helper support back in '12 or so I didn't protect the changes behind a modeswitch. Something I would not do today.

Also the modeswitch itself is definitely required as definitely not all language modes should support advanced records by default (e.g. TP or ISO).

Regards,
Sven

My idea was to maybe add a mode ObjFPCExt or ObjFPCAdv which is quite a bit less conservative and might break backwards compatibility a bit more often when new features are added.

Regards,
Sven

On Apr 14, 2019, at 1:29 PM, Sven Barth via fpc-pascal wrote: > I like what Jonas did for the ObjC mode switch where he named them with versions. Maybe a {$mode objfpc2} one day. My idea was to maybe add a mode ObjFPCExt or ObjFPCAdv which is quite a bit less conservative and might break backwards compatibility a bit more often when new features are added.

That’s a good idea to make a place we can add new mode switches for new language features which 99% of people are going to use. Most mode switches don’t break backwards compatibility but the pending multi-helpers could certainly cause some problems. Array operators could also but can’t think of any others.

Regards,
Ryan Joseph

FWIW: all of the delphi code that i've worked with trying to port to FPC has had this... at least one had an include file that IFDEF'd its way through like 4 or 5 other pascal compilers... to me, once i saw this and realized what it was doing, this seems like the best way and also to be the pascal way...

Jonas Maebe wrote

That was because Apple did the same with the Objective-C language: https://en.wikipedia.org/wiki/Objective-C#Objective-C_2.0 :)

How does $modeswitch objectivec1 differ from objectivec2? That article mentions that Objective-C 2.0 added 64-bit support, but we've only had objectivec1 enabled and our 64-bit builds appear to be working without issue?

Objective-C 2.0 also language features that rely on run time support (which is only available in the Objective-C 2.0 runtime). In FPC, the only extra difference is that fast enumerations are supported through the "for .. in" syntax if that mode is enabled. It indeed does not make any difference as far as 32/64 bit support is concerned.

Jonas