Hi,
Attributes on local variables aren’t working anymore.
Example:
AttributesLocalVar.zip (4.4 KB)
Using RemObjects Elements with Water - 11.0.0.2767 in visual studio.
Thanks in advance.
This never worked. in fact we just fixed to allow this in undefined code, for
bugs://E26068: Delphi Compatibility: Cannot use attribute on local variable, in undefined code, eg
on your request from Build error with conditional defines; using attributes on local variables - #6 by mh.
namespace AttributesNotAllowedLocalVariables;
interface
{$IF NOT ELEMENTS}
procedure DoSomething;
{$ENDIF}
implementation
{$IF NOT ELEMENTS}
procedure DoSomething;
var
//Attributes on local variables used to work with RemObjects Elements with Water - 11.0.0.2743.exe
//But doesn't work anymore with RemObjects Elements with Water - 11.0.0.2767.exe
[&unsafe] name: String;
begin
end;
{$ENDIF}
end.
now will work (and also failed, before).
I don’t quite understand.
Using attributes on local variables always worked, but it didn’t work for inline variables. Since .NET doesn’t support attributes on inline variables. That’s why I wanted to exclude the code with defines, and therefore I wrote the post: Build error with conditional defines; using attributes on local variables - #6 by mh.
You have perfectly solved the issue with an attribute on a inline variable between defines but with this new version, using unsafe on a local variable does not work anymore.
procedure DoSomething;
var
[unsafe] name: String; // This used to work in Elements with Water - 11.0.0.2743.exe, but no longer works in Elements with Water - 11.0.0.2767.exe
begin
{$IFNDEF ELEMENTS}
var [unsafe] age: Integer := 17; // This now works in Elements with Water - 11.0.0.2767.exe, but didn't work in Elements with Water - 11.0.0.2743.exe
{$ENDIF}
end;
Thanks for your support.
Hmm, then this might be a regression. but .NET has no distinction between variables being declared before the begin or inline. In fact, C# doesnt even let you do that. That’s a Delphi thing, and Oxygene only has it for legacy reasons.
But I’ll reopen this as a new issue.
Note that in either case, unsafe is a keyword, and not an attribute in Oxygene, so it will never work on the var decl like tis, even if attributes in general were to be allowed there.
That doesn’t matter, we don’t mind even if the attributes would be ignored. It’s just that in Delphi we’re using the attribute a lot and that would save us dozens of additional conditional defines.
Thanks for your reply and help.
But thats how int works now? if you undefined the attribute it will compile.
We will not have the compiler just ignore active attributes without error or warning, that’d be Bad™. We’ve never done that (and if that code indeed compiled before Xwiotjot error and without adding an attribute, then that was a bug.
A separate argument could be made for specifically allowing [unsafe] as Syntax in Delphi Compatibility Mode; I could consider logging a feature request for this.
Well in Delphi if you use a custom attribute that’s not defined the compiler will just give a warning and ignore the attribute.
procedure DoSomething;
var
[unknownattribute] // The compiler will only give a warning: 'Unknown custom attribute' but will compile
myName: String;
begin
end;
It would be very helpful if in Delphi Compatibility Mode such usage of attributes would be ignored or just given a warning, or just allowing the [unsafe] attribute.
Ouch, nasty.
Yes, that’s a separate issue. I think I’ll close the above as designed (we dont support attributes on local vars, so it should not matter if they are before or after the begin. and both are handled in UNDEFed code.
I’ll log separate issues for supporting [unsafe] in DCM and (less likely to happe, because ugh) to ignore unknown attributes in DCM.
What does [unsafe] do in Delphi (aside from being ignored)?
Logged as bugs://E26133: Delphi Compatibility: [unsafe]/[weak] attributes to map to “unretained”/“weak”.
Low priority, if I’m completety honest, as the compiler team is rather busy and even on Delphi these ar needed only on ARC, which, as far as I understand, is deprecated across all of Delphi.
ARC not is deprecated at all as interfaces use ARC. ARC has been removed from object references though. The usage of [weak] and [unsafe] are quite normal when working with interfaces and they serve their purpose.
Ah, interesting. I was not aware of those being supported on interfaces (which ofc have always been reference counted, since Delphi 3, though not group them under “ARC”, but I guess technically they are).
Note that I don’t believe Elements uses ARC for interfaces (except on Cocoa, where everything is ARC, and for COM references on Island) so you might get some unexpected behaviors there porting code that relies on [unsafe]/[weak] for interface references (which, TBF I never had missed back when I was still using Delphi and extensively used interfaces, well before these were introduced).