Ternary operator values implicit conversion issues

[RadoArvay]

Is it fully by design or sort of a bug?

1. Describe the bug
When I use the ternary operator with one-character text constants as values, I get conversion errors (compiler or runtime) between Text and Character types.

2. To Reproduce
Standard is TextElement from XmlPort, but it does not matter, it can be any Text variable.

Example 1:
Standard := OptionValue = DummyVATReportHeader."VAT Report Type"::Standard ? '1' : ''; (empty text)
Cannot implicitly convert type 'Text' to 'Char' AL0122
It is the compiler error in VSCode. Ok, two different types of values are used, but couldn't it be more looser?
"Negative" definition is OK in VSC, but I did not try to publish and run it:
Standard := OptionValue <> DummyVATReportHeader."VAT Report Type"::Standard ? '' : '1';

Example 2:
Standard := OptionValue = DummyVATReportHeader."VAT Report Type"::Standard ? '1' : ' '; (one-space-constant) or
Standard := OptionValue = DummyVATReportHeader."VAT Report Type"::Standard ? '1' : '0';
AL compiler in VSC does not complain. BusinessCentral will crash when run that code - and it is not debuggable. But in debug mode, VSC shows the conversion error:
Error: C# compilation has failed for the application object XmlPort_nnn.
The failing c# file name is 5F513583CF61537DB8A2B84F5170D2575517F854DED61E60FD0ECD0091A256A3.cs. You can find this file with the associated AL file saved in the C:\ProgramData\Microsoft\Microsoft Dynamics NAV\252\Server\MicrosoftDynamicsNavServer$BC\apps\compilationerrors folder.
Detailed compilation error: C:\ProgramData\Microsoft\Microsoft Dynamics NAV\252\Server\MicrosoftDynamicsNavServer$BC\apps\metadata\3\5F\5F513583CF61537DB8A2B84F5170D2575517F854DED61E60FD0ECD0091A256A3.cs(1242,60): error CS1503: Argument 1: cannot convert from 'target-typed conditional expression' to 'string'

3. Expected behavior

4. Actual behavior

5. Versions:

• AL Language: 14.2.1249978 (I did not test the insider 15.0)
• Business Central: 25.2.27733.28023
• Operating System:
  • Windows
  • Linux
  • MacOS

Internal work item: AB#561007

[NKarolak]

@BazookaMusic This is related to #7926 - but this time, both return parts are string, so this is another issue.

[RadoArvay]

Yes, I saw that issue and I wanted to continue there, but it is already closed and, as you wrote, there are different types.

[BazookaMusic]

Accepting because C# compilation errors is a bug. If it compiles it should run.

However, the conversion errors are because these are the conversion rules for AL. Since the type of the expression is decided by the "true" side, you need to adjust the code so that there is a conversion from the "false" side to the "true" side.

Maybe it makes sense to adjust these conversion rules, so you can add an idea in BCIdeas with some annoying examples.

[NKarolak]

@BazookaMusic

Since the type of the expression is decided by the "true" side, you need to adjust the code so that there is a conversion from the "false" side to the "true" side.

I don't get this. Did you mean that we should adjust the AL code? Why and how - all of the true and false parts above return a string.

[RadoArvay]

No Natalie, it is as the compiler says in Example 1: true part returns Char type ('1') - unfortunately (because it is only one character). false part in my examples is either Text (empty string ''), or Char (one-spaced string ' '). It is very strict implicit conversion. I would be glad if it has been more looser conversion between these two types, but ok, I get it.
They were very special examples. I did not try it, but if I used Labels or Text variables, it would run correctly, I believe.

[BazookaMusic]

One trick that we sometimes use in C# is to do '1'.ToString(), so you can use the Format function on the left side to make sure it's a text.

However, I have to say that the fact that 1 character strings are chars is a pain point.