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
EndOf Line is a method that returns an instance of the EndOfLine CLASS
The reason
Var StrSysOrNotEnded As String = EndOfLine
works is because
the EndOfLine GLOBAL METHOD returns and instance of EndOfLine CLASS
that class has an OPERATOR_CONVERT method thats returns a string ( a convert TO conversion)
In the INLINE version you have
endofline that returns an instance of EndOfLine ( a class)
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)
Ivan pointed such behavior from the manual. The compiler error misses location info (column position pointing the place) to be more clear
a
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.
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