[Solved] Are there any file naming rules to save ampersand prefixed units?

[WooBean]

As I checked in Delphi 2010 there was not possible to save a unit named like "&begin".

Some trials to cheat Delphi IDE by external renaming a file as "&begin.pas" or "begin.pas" were not successful.
Delphi always prevent using "reserved" word despite using "&" at the beginning of a unit name.

Current FPC and Lazarus seem to be more tolerant. It is possible to use a unit named "&begin" with corresponding file "begin.pas" or "&begin.pas".

Let us imagine that we are stating a rule which version should be implemented as default Lazarus IDE behaviour -
(1) save/rename to file with file name containg '&' prefix;
(2) save/rename to file with file name without '&' prefix.

My personal choice is version (1).

Maybe this was already decided somewhen?
 

[440bx]

I think that if the ampersand appears in any occasion then it should always appear.

Consistency is important to ensure the file is always treated the same way which cannot be guaranteed if the ampersand in is significant in some situations and not in others.

my $0.02

ETA: edited typo

[TRon]

Some filesystems/OS' do not allow an ampersand in a filename (or has a special meaning).

[marcov]

I wouldn't recommend abusing &. It was meant for COM interfaces that are externally named, not as the end of keywords.

[MarkMLl]

I wouldn't recommend abusing &. It was meant for COM interfaces that are externally named, not as the end of keywords.

I'd consider it to be extremely inadvisable, and would also advise extreme caution when choosing embedded separators.

Stick to "identifier style" filenames, i.e. start with a letter and continue with letters and/or digits. Use _ as a separator if you have to, avoid e.g. $ since even though it made sense on ISIS it's risky with anything more modern (i.e. just about anything)... same applies to &, quotes, slashes and so on.

Think carefully before using camelcase.

Subject to case significance/preservation and length limitations, the above should be good for most current OSes.

MarkMLl

[Thaddy]

If that works, consider it a bug and report it.

[n7800]

I think that if the ampersand appears in any occasion then it should always appear.

Consistency is important to ensure the file is always treated the same way which cannot be guaranteed if the ampersand in is significant in some situations and not in others.

I agree. As far as I know, escaping keywords with ampersands is important for compatibility in some cases. And if Delphi does not allow it, then this makes fpc an advantage, which is, as all know, more portable.

However, WooBean, I would like to clarify at what level of Delphi this is "prevented"? Have you tried calling the compiler directly?

Some filesystems/OS' do not allow an ampersand in a filename (or has a special meaning).

At which ones exactly? File systems used in Windows (FAT32/NTFS) definitely allow this, and in Linux (EXT4) there are almost no restrictions at all.

This sign can be interpreted in the terminal, but it can be escaped.

And this all is not so important, since only escaping keywords in the code is mandatory. That is, the file can be called simply "begin.end.pas", but in the code it must be written "&begin.&end".

I wouldn't recommend abusing &. It was meant for COM interfaces that are externally named, not as the end of keywords.

Can you give an example? I saw somewhere the use of "interface", but I never looked into it. I only found this information, in which I do not see the use of the ampersand.

[n7800]

Actually, I have long wanted to propose a feature request so that when entering a file name (or a variable when renaming via [F2]) containing keywords, the IDE automatically adds "&".

But before doing so, it should definitely ask for confirmation to indicate that this is not recommended. I think this is especially useful for newbies who might accidentally specify a keyword as a name. For example, IDE could show:

"begin" is a keyword and its use as an identifier is not recommended. If you continue, it will be escaped with "&".

BTW, there is already a similar warning when entering a "strange" file name when saving (see attachment).

[TRon]

And this all is not so important, since only escaping keywords in the code is mandatory. That is, the file can be called simply "begin.end.pas", but in the code it must be written "&begin.&end".

I agree but that is not the preference of TS and suggestion from the additional first comment from 440bx.

Let us imagine that we are stating a rule which version should be implemented as default Lazarus IDE behaviour -
(1) save/rename to file with file name containg '&' prefix;
(2) save/rename to file with file name without '&' prefix.

My personal choice is version (1).

and

I think that if the ampersand appears in any occasion then it should always appear.

Those seem to suggest to change the actual filename as stored.

There are several issues with that (I extend my original answer as it seems unclear what impact such a change can have):
- OS/DOS not supporting such kind of characters
- software (filemanager/shell) not supporting such kind of characters
- filesystem not supporting such kind of characters
- Toolchain(s) not supporting such kind of characters.
- intermediate solutions like SMB and 3th party filesystem-drivers that do not support such kind of characters

And that is besides the fact that the ampersand is only used as an escape in the compiler so it makes no sense to let that influence anything else (outside the compiler). To that we seem to agree 

Hence the reason for my initial reaction.

Things are already going fantastic with spaces in path and filenames 

It was not that long ago (perhaps still is ?) that M$ applications showed a underlined character when using an ampersand.

[WooBean]

Actually, I have long wanted to propose a feature request so that when entering a file name (or a variable when renaming via [F2]) containing keywords, the IDE automatically adds "&".
But before doing so, it should definitely ask for confirmation to indicate that this is not recommended. I think this is especially useful for newbies who might accidentally specify a keyword as a name. For example, IDE could show:

"begin" is a keyword and its use as an identifier is not recommended. If you continue, it will be escaped with "&".

I am a bit against suggesting usage of &-prefixed identifiers. Such identifiers should be used rather as an exception to survive automatic code translation from old Pascal or even any programming language. If a user can't choose a proper value for naming an identifier so saving and/or renaming should be aborted without giving an "&" usage hint.   

Back to file naming:
- naming files with added "&" is less portable, so safer option is using "begin.pas" convention.

BTW, there is already a similar warning when entering a "strange" file name when saving (see attachment).

This is a result of calling SysUtils.IsValidIdent - which is "dotted ready" but not "ampersand ready". For FPC such identifier "&begin.&end" is no problem (FPC 3.2.2 for sure). Dotted identifiers are meaningful only as source names (projects or units), of course.

[WooBean]

If that works, consider it a bug and report it.

Part of Lazarus code responsible for checking if a unit name fits to some file name uses a function CompareDottedIdentifiers (or CompareDottedIdentifiersCaseSensitive) which - as for trunk development status - allows using even multiple ampersands.

For comparing rules "begin.end" is equal to "&begin.&end" but first expression ("begin.end") can be used only as part of a file name (short file name without extension) but not as a Pascal identifier. The second expression  can be used in both cases as a short filename and as an identifier.

Imo, it is not a bug. A first fitting file will be accepted.

For a dotted identifier "&begin.&end" its fitting file can be (an extension can be also ".pp", ".lpr"):
-"begin.end.pas";
-"&begin.end.pas";
-"begin.&end.pas";
-"&begin.&end.pas".

[PascalDragon]

Current FPC and Lazarus seem to be more tolerant. It is possible to use a unit named "&begin" with corresponding file "begin.pas" or "&begin.pas".

The ambersand is only intended for the identifier inside the unit. File names themselves are not identifiers, thus that a file called &begin.pas for a unit &begin works, is to be considered a bug. It must be begin.pas instead. So please be advised that this might be fixed in the future.

[n7800]

Actually, I have long wanted to propose a feature request so that when entering a file name (or a variable when renaming via [F2]) containing keywords, the IDE automatically adds "&".
But before doing so, it should definitely ask for confirmation to indicate that this is not recommended. I think this is especially useful for newbies who might accidentally specify a keyword as a name. For example, IDE could show:

"begin" is a keyword and its use as an identifier is not recommended. If you continue, it will be escaped with "&".

I am a bit against suggesting usage of &-prefixed identifiers. Such identifiers should be used rather as an exception to survive automatic code translation from old Pascal or even any programming language. If a user can't choose a proper value for naming an identifier so saving and/or renaming should be aborted without giving an "&" usage hint.   

I agree that this method should not be recommended, that's why I said about mandatory warning the user and explicit advice not to use it. But for the sake of the ability to migrate old or incompatible code, it cannot be prohibited at all.

It's like the -f (--force) flag in many utilities. For "dangerous" operations, you can ask the user to explicitly specify it, but it's absurd to prohibit the user from performing such an operation at all. Besides, escaping identifiers is not such a scary operation that the user needs to be protected from it.

It was not that long ago (perhaps still is ?) that M$ applications showed a underlined character when using an ampersand.

"Keyboard accelerators" are a very useful feature that I use all the time. But their appearance on the editor tabs is accidental, so merge request !321 was created.

Current FPC and Lazarus seem to be more tolerant. It is possible to use a unit named "&begin" with corresponding file "begin.pas" or "&begin.pas".

The ambersand is only intended for the identifier inside the unit. File names themselves are not identifiers, thus that a file called &begin.pas for a unit &begin works, is to be considered a bug. It must be begin.pas instead. So please be advised that this might be fixed in the future.

Well, perhaps normalizing file names (removing ampersands) will be useful. This will eliminate ambiguities (several possible forms of the same thing) and potential "inconveniences" listed by TRon (with terminals, programs).

[WooBean]

Well, the final conclusion is:

save or rename units (projects) containg "&" prefix(es)  to file named without using ampersands (&).

Example:

unit "&begin.&end" will be saved in file named "begin.end.pas".

[Thaddy]

And that would be a great idea?