String concatenation feature or bug?

So..., no one can articulate a when or why this would solve a problem? I haven't had to do this since I migrated from Fortran IV to Fortran 77 when strings became a data type and I could quit picking bytes out of integers.

Can you articulate why Monkey C's behavior is wrong except to say you initially didn't understand it, you don't like it, you don't need it and you believe that concatenation operations would be faster and more memory-efficient if a Char could be concatenated with any other data type, resulting in a String?

Just because you can't see a use for something, doesn't mean it shouldn't exist.

At least I can say it's fairly consistent with other languages.

- In C, a char is simply a single byte integer

- In Java, when you add an integer to a char, you get an integer (the result of adding the underlying numerical value of the char to the integer)

Monkey C is close to Java, except that the result of adding an integer to a char is still a char.

Even if I agreed with everything you said, what difference would it make? Garmin is not changing this.

andyj713 said:

I haven't had to do this since I migrated from Fortran IV to Fortran 77 when strings became a data type and I could quit picking bytes out of integers.

By the same logic, do you think & (bitwise AND), | (bitwise OR),  ^ (bitwise XOR), << (left shift) and >> (right shift) should be removed from Monkey C? Who's looking at individual bits these days amirite

(I used bitpacking in data fields to save memory tho)

andyj713 said:

So..., no one can articulate a when or why this would solve a problem?

Your alternative doesn’t solve a problem. 

Worse, changing the behavior might break existing code. 

flowstate said:

Garmin is not changing this

I know this very well. I have found more than one bug, one of which caused hard reboots of my watch. They haven't fixed any of them. They broke makeImageRequest for CIQ 4+ watch faces, no sign of that getting fixed.

andyj713 said:

I know this very well. I have found more than one bug, one of which caused hard reboots of my watch. They haven't fixed any of them. They broke makeImageRequest for CIQ 4+ watch faces, no sign of that getting fixed.

As extremely frustrating as Garmin's bugs and poor design decisions can be, I don't count this as one of them.

I use some bitpacking because it's easier than a handful of booleans and it can simplify if logic, which also saves bytes and minimizes glitches when passing data between watch face and background.

This falls into the gotcha category. Kinda like how commas save lives.

Uh ok if you say so.

I'm just saying I think the behavior you're complaining about is neither a bug nor a poor design decision, and I implied that I wouldn't count it among those bugs you are complaining about. It's not a bug or bad design decision to be "fixed", it's just behavior you don't like.

Yes, clearly that's a subjective opinion of mine. I mean it's clearly not a bug, but you could argue it's a bad design decision. I wouldn't, but clearly you are.

And I'm also saying that I too have been frustrated by many annoying Gamin bugs (in CIQ and in general).

In this case, I can't objectively say Garmin's behavior is "good" or "desirable" (according to some unspecified arbitrary standard) any more than you can definitively say it's incorrect.

You didn't even understand what was happening in the first place, nor did you understand what happens when you type '' in Monkey C source code (the truth was far simpler -- and dare I say consistent -- than what you had assumed) so I wouldn't throw stones if I were you. Funnily enough the same pattern occurred in both cases: you were unable or unwilling to take some simple steps to experiment with the poorly understood (by you) behavior to figure out what was actually going on.

In the case of what you complained about in the OP, the use of literally any other integer than 0 for _nextPos would've given you a huge hint as to what was happening. (This is one of the benefits of trying to reproduce puzzling behavior in a simple code fragment that others can easily consume - it avoids "magic" values which are related to your larger program which may obscure what's going on in the code of interest.)

In the case of '', placing '' almost anywhere else besides the argument to System.println() would've given you a clue that the compiler simply ignores '' as opposed to doing some kind of weird special case optimization when it's the final argument to a function or something. You couldn't even articulate exactly what you thought '' is supposed to represent - what's a "nullish" character?

andyj713 said:

I use some bitpacking

Oh good, as long as you use it, Garmin can keep it in the language