I was merely indicating syntactical elements, not the use of specific units, variables and constants, not even the RTL as such. So, much like $mode objfpc extends the syntax let $mode delphi restrict the syntax.
There is a case to make that f.e. the C style operators and the macro facilities belong to $mode objfpc anyway.
Or am I wrong here?
Or is there value in it?
In that case I will have a look if I can create a patch for a $mode strictdelphi (or whatever name is convenient).
It should merely exclude extended syntactical elements not available in Delphi compared to the current Delphi compatibility support.

Sorry about the location of my last post regarding this.

BTW I am aware I can solve this at the sourcecode level with defines - I just did that -, but would prefer one of my suggestions.

The point is that even if you disable all those syntactical elements, then your code may still not be compilable by Delphi in any way (which I believe was your goal).

They are not part of either {$mode objfpc} or {$mode delphi}. You have to explicitly enable them in addition to the syntax mode, via e.g. the {$coperators on} resp. {$macro on} directives.

Or is there value in it?

Some people prefer the general Delphi syntax (e.g. because they are used to it), but still don't mind writing code that only runs under FPC for whatever reason. I'm mainly talking about differences related to procvar syntax, how the name of a function is interpreted in its body (as a recursive call or as an alias for the function result) etc.

Jonas

mode delphi is used in a huge amount of code, so any break in backwards compatibility here would be extremely unwelcome. It surely would break a lot of code that I wrote.

But yes, $mode strictdelphi looks like a good idea if you want to implement it.

Felipe Monteiro de Carvalho wrote

mode delphi is used in a huge amount of code, so any break in backwards compatibility here would be extremely unwelcome. It surely would break a lot of code that I wrote. But yes, $mode strictdelphi looks like a good idea if you want to implement it.

Provided it is limited to the compiler itself - which is what I want -, I think I may be able create a patch.
If there is more demand for it.

Then there are the three options on how to implement: Should it generate a hint, a warning or a syntax error in case of a violation?
I suggest a 'warning: % is not supported by Delphi'. That way code generation continues, which seems correct, because the generated binary will still work.

Which Delphi version would be the supposedly supported one? If this is not explicitly defined, compilation might still fail when people using lower Delphi versions try to compile the code. Do you really want to track the feature set (especially for smaller parts like that certain feature exists in Delphi but FPC extends the scope of the feature to a wider set of cases)? I'd say that there is already enough bug reports about FPC not eating Delphi code. Does anyone really want to start fixing FPC also for bug reports about Delphi not eating code compilable with FPC? If someone wants to support compilation of his code with a specific Delphi version, can he do it without really compiling it with Delphi (and also testing the result!) before publishing the code anyway?

Tomas

There's a documented delphi version: almost complete D7 support *by the compiler* and by now d2006 now almost feature complete. If you read me correct, I won't try to do any rtl related stuff. It is sufficient to protect against obvious compiler incompatibility, macro's, C type operators. Nothing else. Most of them are compiler switches, not library features. Throwing a warning in these cases has real value for me. (I am running my own rtl and libraries anyway: KOL+ system unit replacements for fpc and delphi 3-2010).
So, no, I agree, this should not and probably can not pursue any or all incompatibilities.
It can pursue however, to try to make life easier for people who need both single sourced FPC and delphi code.
I do not plan to extend on $mode delphi which is documented as almost 100% Delphi7 compatible,
I am trying to restrict Delphi mode a Little further. Only on the compiler level and only the obvious. Just like it pretends to be the case already. $STRICTDELPHI is probably a bad name. Open for debate as I wrote before.

In our previous episode, Thaddy said:

There's a documented delphi version: almost complete D7 support *by the compiler* and by now d2006 now almost feature complete.

That goes for the release branch that is already in freeze. New features will go into trunk, which will have, among others, the unicode changes, and probably many other D2009+ features.

Thaddy wrote

There's a documented delphi version: almost complete D7 support *by the compiler* and by now d2006 now almost feature complete.

That only works in one way: the compiler can support most of D7 and D2006, but if you check for everything the compiler supports then the guarantee can only be that the code will be compilable by D2006. It won't say anything about compilation with earlier Delphi versions (unless you add, as Tomas mentioned, separate STRICTDELPHI modes for different Delphi versions).

I am trying to restrict Delphi mode a Little further. Only on the compiler level and only the obvious. Just like it pretends to be the case already.

Delphi mode is not about restrictions. Delphi mode is about changing the compiler's behaviour so that Delphi code can be more easily compiled with FPC, e.g. different procvar syntax, don't require that parameter lists are repeated in the implementation unless you are overloading, allow identifier conflicts between fields and method parameters, ... I think most of the changes that are not simply about syntax differences, make the compiler in fact less strict rather than stricter.

$STRICTDELPHI is probably a bad name.

It actually perfectly describes what you want to do, be it only regarding things that can be checked by only relying on the compiler. I'm not sure whether the limited applicability of such a feature (mainly usable if you don't use, like you, the standard RTL of either FPC or Delphi) makes it worth it to add a ton of small checks sprinkled all over the compiler though.

Jonas

Thaddy wrote

On 29-11-2011 18:49, Tomas Hajny wrote:

.
.

.
.

As pointed out by others, the Delphi 7 reference doesn't imply that there are no features only available in later Delphi versions.

What is "obvious" is also questionable, IMHO - I don't own/use Delphi myself, but I believe that e.g. ability of FPC to use properties outside classes is not supported in Delphi. Does that still belong to the "obvious" category from your point of view (although it is not a standalone language construct but just an extension of a construct supported in Delphi)?

Again, I'm not a maintainer of the compiler code so I probably won't have to tackle the increased complexity of the compiler/parser code myself, but the ratio between benefits and costs (compiler slow-down due to many added checks not necessary for compilation plus more importantly the increased complexity of both the existing code and also maintenance of the proposed feature required in the future) seems to be fairly bad in this case... I understand that you may benefit, but I'd also say that your case is fairly specific (most FPC users use also the supplier RTL, etc.).

Just my two cents (I'll try not to comment on this any further to avoid endless discussions and I won't be the one assessing any potential patch coming from your side providing implementation of that proposed feature)...

Tomas

An audit of what and how it can be done confirms this. It can be done, but not by me and I can live with my conditional defines. Pity it's so hard to make it work both ways.