Lars Fosdal

There is a lot of strange code in that helper. Have a look at function IsEmpty, which compares the string to a record local const Empty - when the unit already has a global constant EmptyStr. Go figure.

It could have had a parameterless overload that could be used for the instance. if string.IsNullOrWhiteSpace(s) then Writeln('Yup'); if s.IsNullOrWhiteSpace then Writeln('Yup'); As it is now, only the first construct is supported.

Also, on the term "AI": Uncovered in https://www.bloomberg.com/opinion/articles/2023-03-26/even-with-chat-gpt-4-there-s-no-such-thing-as-artificial-intelligence

Like the latter, yes. Then there is the question of codepage. What if we combine Unicode characters that are not available in the same codepage in the same set of ansi characters? I guess that will fail. AnsiString has codepage declaration support - but AnsiChar does not. Relevant read: Marco's Tech Paper https://www.embarcadero.com/images/dm/technical-papers/delphi-and-unicode-marco-cantu.pdf True - but look at InOpArray. Technically it would be possible to have a in operator that checks if a value exists in an array that would be syntactically identical to value in set. Whether it would be efficient or not with even more compiler magic is questionable.

/on-topic This is application of "AI" in ways that I can like https://visualstudiomagazine.com/articles/2023/03/23/vs-ai.aspx

Interesting. Did they have other plans once upon a time? This means it would be safer with if/then/else structures when testing for Unicode chars. or use var ch: char; begin ch := '€'; if System.WideStrUtils.InOpArray(ch, ['æ', 'ø', '€']) then DebugOut('Yup'); but that is just a sequenctial scan of a widechar array.

/off-topic Me: I need help defusing a bomb AI: What kind of bomb Me: posts a series of photos of the bomb AI: Cut the red wire ... *BOOM* AI: ... after cutting the green wire

The input char is mapped correctly. For keyboards with national keys (f.x. äöæøå etc in Nordic), it at least works correctly. Not sure how it translates source code to AnsiChar, considering that source code can be UTF-8. procedure TestChar; var ch: char; begin ch := '€'; if ch in ['æ', 'ø', '€'] // gives [dcc32 Warning] : W1050 WideChar reduced to byte char in set expressions. Consider using 'CharInSet' function in 'SysUtils' unit. then DebugOut('Yup'); end;

https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.SysUtils.CharInSet is the recommended method for checking if a character is in a set. It handles Unicode correctly.

Please make a minimal app that reproduce the problem, and create an issue on https://quality.embarcadero.com Remember to give a good step by step description of how/when it fails.

It seems someone lost their thread...

I'd be interested in reading a summary of your findings!

@Rollo62 I think we can say without doubt that none of us wants an AI like the one in the Terminators. I do want AI that is accurate and reliable for the areas that it is applied to.

Threads are not hard, as long as you play by the rules as described by @Dalija Prasnikar There is also good advice in OmniThreadLibrary by @Primož Gabrijelčič

Finding tools for Delphi is not easy. Look at GitHub - out of some 27+ million public repositories, less that 3k are Delphi. Not much material for the AIs to make patterns from. GitHub Advanced Security has no tools that can be directly leveraged for Delphi.

For sure! Who needs an AI to f... things up, when I am perfectly capable of f...ing stuff up myself? 😄

@hsvandrew There is no doubt "AI" (Machine Learning) will impact our work and business systems. What's wrong with me, is that I don't care for a deluge of "My AI generated code doesn't work. Why?" posts.

What can I say - I like open source where the source is included.

Consider type Use = record public class function When<T>(const aBool: Boolean; const WhenTrue: T; const WhenFalse: T): T; static; inline; end; { Use } class function Use.When<T>(const aBool: Boolean; const WhenTrue, WhenFalse: T): T; begin if aBool then Result := WhenTrue else Result := WhenFalse end; procedure Test(Cond: Boolean); type TObjectClass = class of TObject; var i: Integer; b: Byte; c: Cardinal; w: Word; s: String; d: Double; o: TObjectClass; begin s := Use.When(Cond,'True', 'False'); s := Use.When(Cond, 1, 2).ToString; i := Use.When<Integer>(Cond, 1, -2); b := Use.When<Byte>(Cond, 1, 2); c := Use.When(Cond, 1, 2); w := Use.When(Cond, 1, 2); d := Use.When(Cond, 3.14, 42.0); o := Use<TObjectClass>.When(Cond, TObject, TStringList); end; This is valid code. But i := Use.When<Integer>(Cond, 1, -2); requires the type to be specified. Also w := Use.When(Cond, 1, 128); stops working - actually for any signed or unsigned type - when the second parameter is changed to 128 or higher. It then complains: Why? I though the left hand type would assist in the type inference and hence the parameter validation? Edit: I just noticed that this only happens for Error Insight - not during compilation.

Thank you, @Stefan Glienke - that clears up the fog. It would have been nice, though - if the left side would be able to hint the type.

I guess I was trying to find out which of the constructs that was more readable.

FFS... I need to log off. Scrolling further up in the source code, I found... type Use<T> = record public class function When(const aBool: Boolean; const WhenTrue: T; const WhenFalse: T): T; static; end; { Use<T> } class function Use<T>.When(const aBool: Boolean; const WhenTrue, WhenFalse: T): T; begin if aBool then Result := WhenTrue else Result := WhenFalse end;

Changed the w line to w := Use<Word>.When(Cond, 1, 32000); That works too!

o := Use<TObjectClass>.When(Cond, TObject, TStringList); I did indeed mean o := Use.When<TObjectClass>(Cond, TObject, TStringList); but nevertheless, it compiles. Go figure.

The code compiles without a warning - also for that last line, @Stefan Glienke. In fact, even b := Use.When<Byte>(Cond, 1, 300); compiles. That is a bit weird, I think. Edit: Note to self - make sure you compile the project that contains the file you are fiddling with.