Funny compiler bug


The destination, the left side of the attribution, is String, all the operands of an “inline” (not function) IF are strings, in case of any of those contents having some type of type selection,

Var StrSysOrNotEnded As String = If (True, EndOfLine, "")

But, the arguments are NOT all strings :slight_smile:
EndOf Line is a method that returns an instance of the EndOfLine CLASS
The reason

Var StrSysOrNotEnded As String = EndOfLine

works is because

  1. the EndOfLine GLOBAL METHOD returns and instance of EndOfLine CLASS
  2. that class has an OPERATOR_CONVERT method thats returns a string ( a convert TO conversion)

In the INLINE version you have

  1. endofline that returns an instance of EndOfLine ( a class)
  2. a text literal
    and an inline if MUST have compatible return types

Add this extension method

Public Function ToString(extends eof as EndOfLine) As string
  Dim s As String = EndOfLine
  return s
End Function

and then this works

Var StrSysOrNotEnded As String = If (True, EndOfLine.ToString, "")

In a real ternary operator, it means nothing, it should be v = x? y : z; "what type we expect for v? String. Solve the ternary boolean x. Is x true? Yes:( can y be solved as String? Yes:(solve y) NO:(Error)) NO:( can z be solved as String? Yes:(solve z) NO:(Error))

But Xojo is… different.

I liked your extension, I’ll adopt it from now on. Right now, for what I needed, it’s 'self solved":

Public Sub Log(msg As String = "", AutoEol As Boolean = True)
  LastErrorLog = LastErrorLog + If(AutoEol, msg+EndOfLine, msg)
End Sub

Xojo considers the types of the two params to the if operator before it worries abut whether they can be coerced / converted to the result
And they have to be the same type (not just possible top convert to the same type)

hence the compiler error

Ivan pointed such behavior from the manual. The compiler error misses location info (column position pointing the place) to be more clear


Var StrSysOrNotEnded As String = If(AutoEol, EndOfLine, "")
**Error**: “Type mismatch: Expected class EndOfLine, but got TextLiteral”

Should be something like:

Var StrSysOrNotEnded As String = If(AutoEol, EndOfLine, "")
                                                        ^-- Error
Error: Type mismatch: Expected class EndOfLine, but got TextLiteral.

I didn’t expect such error as Xojo interprets, but if EndOfLine is a Class that can’t convert to String in such context, with an IF inline (not Xojo version) the first one should be:

Var StrSysOrNotEnded As String = If(AutoEol, EndOfLine, "")
                                             ^-- Error
Error: Type mismatch: Expected String, but got class EndOfLine.

determining intent is not something compilers are good at
maybe you wanted the if to return a string ? or a class ?
it cant figure out which so you get the error in a general way
basically “I have no idea which you meant”

The target is String, so I want String. Most compilers evolved to extract most from the context even before runtime, the compiling context is clear in the above example.

The compiler DOES NOT consider that the target is a string
Never has with any data type
The inline IF requires parameters 2 and 3 be the same type

The Xojo compiler. Not others.

Take Rust for example:

Now let’s move the error to other position:

ok but the issue isnt with other languages so that really doesnt matter
its irrelevant what other compilers do since they dont compile Xojo code

Xojo’s compiler doesnt do this
File a feature request to ask them to make such a change to the compiler

Nah… The point was that I expected the usual ternary behavior without knowing the Xojo eccentricity. Now I know. I don’t need they fix it because they don’t have people able to introduce such demanding change and work in other more important front-lines at the same time. Better they find a way to explain better some error messages, just it.

in a way it is a bit odd since something like comparison (if doubleVar = intVar) will promote to a common type to do the conversion

that the inline if doesnt try to do that is different

I dont know if this has been report ed or not but I already have a bunch of compiler bug reports that remain unresolved and ones that I know can be solved fairly readily have been closed as “not a bug” so I would not hold my breath