Saying that Xojo must abandon what Computer Science mathematically stands as true because “We heard that Peter, the farmer, wrote a wrong routine in the past that can be affected if we fix this” is just insane. Tell Peter what you said to Web 1.0 people, don’t use a new edition for your legacy code or adjust your code. If someone ports code from other platforms to Xojo, Xojo will unexpectedly break it. What Xojo does wrong with “UInt Compare UntypedNumericLiteral” is that it does a lazy promotion of UnsignedNumericLiteral to a signed Integer, instead of promoting the untyped to the same level as the left operand that is typed (the highest common one), that is a Uint32 (the literal 0 fits a Uint32). The Xojo behavior is simply wrong. Here is the proof, click Run. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f9787c3bb2c383793482c8c4b859086c
I want to make something very clear. I’m not advocating for changing how literals are defined. While I think we need some more control over how constants are defined, that’s not my goal either.
I want the comparison to change. The issue at hand is that Xojo tries to find a common type between the two integers getting compared. This is literally impossible to get right in some scenarios. Imagine if I filed a bug report because the following code doesn’t “work.”
Var FirstValue As UInt32 = 4294967295
Var SecondValue As Int32 = FirstValue
// SecondValue does not equal FirstValue!
It’d be closed promptly because that is very clearly an expected behavior. This is precisely what Xojo is doing when we try to compare a UInt32 to an Int32.
What I’m advocating for is to fix the comparison. I think the compiler should be able to evaluate this correctly:
Var FirstValue As UInt32 = 4294967295
Var SecondValue As Int32 = -2147483648
If FirstValue > SecondValue Then
// Do Something
End If
In this case the effect is the same. FirstValue will be converted to Int32 for comparison. There’s no way type conversion can handle this code. Either FirstValue becomes wrong, or SecondValue becomes wrong. Xojo needs to stop converting data types for comparison. According to Aaron, it was done this way because it’s simpler. That doesn’t make it right.
I’m not saying this is a simple fix. It’s definitely outside my skillset, and considering Xojo doesn’t have a compiler engineer, probably outside Xojo’s ability to fix. But that doesn’t mean it’s not a bug, and trying to brush it under the rug is not going to make this go away.
Comparing numbers “correctly” is more crucial, IMO, than feature requests at this point.
There are descriptions and there are facts 
Would one think “if 0>10 then” returning true as being wrong by facts/maths or right by descriptions?
Such a core feature is bugged in Xojo and it’s not even thought as a solvable problem (for obscure reasons about “backward compatibilities” where no example can be shown). Does this sentence even sound possible? 
man_shrugging:t2:
If you follow the SQLite Users Mailing List, you’ll see that a few times a year change requests are refused to ensure backwards compatibility. And no examples are given.
This can apply to bugs, too. Here’s this from a post today:
"… a PRIMARY KEY is not allowed to have NULL values in normal SQL.
This is enforced in most all SQL engines, but a peculiar bug in SQLite, now maintained for backward compatibility, has allowed SQLite-specific PK’s to contain NULLs. …"
So there is nothing unusual, per se, in what Geoff is suggesting.
I don’t follow the databases topic, as I know next to nothing about them (even your quoted code makes no sense to me…).
I don’t have the knowledge whether the database discussions are as core as comparing numbers; are the examples you’re talking about also undoubtfully bugs?
All he means is it’s not uncommon for a vendor to refuse to fix a bug, and not cite a real reason beyond just hand-wavy “backwards compatibility.”
And that’s fine. They have the right to do so. Just like I have the right to give them a hard time about it.
I’m more inclined to trust fairness than rights…
The SQLite folks claim there are 1.0e12 SQLite databases in active use. So for them, “backwards compatibility” is more than just a “hand-wavy” notion. See the Home and About pages at sqlite.org.
I use Uint and it’s derivatives frequently on Windows Desktop. Graphics and video appear to be well-supported for mac, while video and graphics on Windows typically heavily relies on declares and plugins which use UInt data types.
Electronics work on the Raspberry Pi requires the use of UInt and other data types that I use frequently.
I love how this conversation has evolved into trying to justify our use of core language features.
This thread is a good illustration of the problems that Xojo is facing. What should’ve happened:
- bug is reported
- fixed quickly
- with a compatibility flag or compiler #pragma if backwards compatibility is needed
Instead, dozens if not hundreds of hours of Xojo and customer time is being wasted going around in circles. Very frustrating.
Given that this specific issue is only one of probably 100 similar issues, I think this shows how the system is broken.
I am curious as to why you think I, as a “citizen developer”, am so different from the “average” Xojo user?
Is it because I have used the product for over 19 years?
Is it my profession as a scientific professional? (I am a chemist)
Is it just because I use Uint datatypes?
Is it because you think I am strange? 
And the more basic question is how can you really know (not just intuit or make assumptions from feedback - which is not good way for all the reasons people here pointed out) what language features people use and what percentage use them?
-Karen
I am doing that in the project I am working on right now.
-Karen
Uint16, Uint8 are both essential for the development of network protocols that use overloading nCounters as sequence numbers. Their use and behavior is vital in the development of many protocol algorithms such as the sliding window, selective repeat, AIMD congestion control and cumulative acknowledgement.
My latest projects are stuffed to the gills with uint16 and uint8 precisely because of their unique properties and for interoperability with other systems who also use them. ie. 65,535 ports (uint16)
Didn’t you know you’re supposed to use Integer for everything? Why use UInt16 for your socket’s ports, when Integer will work just fine? Do it like Xojo’s own sockets! Negative ports are awesome!
(Yes I’m being sarcastic.)
I do prefer to use integer, even for Uint16 values.
So for a plugin class, you may have a port property being Integer and if you use a value out of range, you may get an out of bounds exception later or an error.
We standardised on Int32 rather than Integer as it meant that overflows would be the same in 32 bit & 64 bit builds.
This case, with 2 strong typed values, of the same size, the compiler should point a type error and ask the dev to explicitly cast/convert the parts to proper types. The only way to satisfy the way you intend, is converting both to a signed higher container like Int64. Look at this behavior: Rust Playground