Can the compiler warn about real errors that cause runtime exception?

I have an app with minApiLevel="1.2.0". It's used by a few hundred users only, so it's more than likely that none of them uses epix (gen1). I just did that, I "accidentally" ran it in the simulator, and got a runtime exception because use Array.slice that is only since CIQ 1.3.0. So of course this is my bug, but I wonder if it would be possible for the compiler to be a little bit smarter (that me and it's current version) and warn me about this? After all I use strict type check, it warns me about even things I can't fix (and that are not a bug at all), i.e:

WARNING: epix: MyDF/source/Config.mc:25,8: '$.Toybox.Application.AppBase.setProperty' is deprecated.

So instead of (or at least besides) these useless and annoying warnings, it could do some good and warn me when I compile for a device with lower CIQ level, that I use an api that will probably cause runtime exception. It's really possible in this case, as I just have:

function foo() as Array<Number> {
// ....
return arr.slice(0, n);
}

strict type check, no annotation to disable any check, and most importantly no has check, like: if (Array has :slice) ...

I realize it's a bit more complicated, as it'll have to fix existing bugs (like the above about setProperty, which is in the else block of: if(Application has :Properties ) but is this a realistic feature to ask for?

flocsy🤠 8 days ago in reply to FlowState

Yes, I would be the 1st to start to open such additional feature-requests (maybe eve I would call some of them a bug) but I don't think that is a bad thing. I mean Garmin isn't a classic agile start-up, no matter how you look at them, but they do incrementally improve the compiler, so why not doing the same with these as well. They can always decide not to add additional features.

FlowState 8 days ago in reply to flocsy🤠

flocsy🤠 said:
I think your native language is English, isn't it? Isn't this what you wanted to write:

- see a warning about neither X nor Y

- see a warning about both X and Y

Yes you are correct.

Perhaps even better:

"- see warnings about neither X nor Y"

"- see warnings about both X and Y"

FlowState 8 days ago in reply to flocsy🤠

flocsy🤠 said:
Yes, I would be the 1st to start to open such additional feature-requests (maybe eve I would call some of them a bug) but I don't think that is a bad thing

I never said it would be a bad thing to open such a feature request.

I've opened such feature requests and made similar threads many times in the past.

I simply tried to answer your question - "is this a realistic feature to ask for?" with my own educated guess of why things are the way they are. I assume this thread was a good faith attempt to engage in discussion, right? Not just a way to provoke responses so you could shoot them down?

I have actually thought about this exact topic (with respect to the deprecation) as I posted a bug report about the deprecation warning a long time ago. And the argument that I laid out about Garmin being unable to be sure whether certain code would be called at runtime was something I came up with independently around that time, when trying to figure out why Garmin wouldn't/couldn't make the deprecation warning "smarter" (so it doesn't appear for devices where the item in question actually isn't deprecated). I didn't come up with the argument 5 seconds ago simply to argue in this thread.

I did say it would be interesting to hear Garmin's perspective which kind of implies opening a feature request / bug report. I guess I could have made that explicit, sorry. Either way, you don't need my permission or approval to open a bug report.

FlowState 8 days ago in reply to FlowState

FlowState said:
flocsy said:
I think your native language is English, isn't it? Isn't this what you wanted to write:

- see a warning about neither X nor Y

- see a warning about both X and Y

Yes you are correct.

Perhaps even better:

"- see warnings about neither X nor Y"

"- see warnings about both X and Y"

Since we're nitpicking this kind of error now:

flocsy🤠 said:
(maybe eve I would call some of them a bug)

*even

flocsy🤠 said:
I mean Garmin isn't a classic agile start-up, no matter how you look at them

"isn't", "them"

I think Garmin should either be treated as singular (e.g. American usage) or plural (e.g. UK) usage, not both.

flocsy🤠 said:
so why not doing the same with these as well

*do

Yes, I nitpick a lot too (but usually when I think the error is actually substantial *), so it's totally fair if I get nitpicked.

[*] as in the error actually reflects a subtle misapprehension or form of misinformation, which actually happens a *lot* on these forums, inside and outside of the CIQ subforums

FlowState 8 days ago

flocsy🤠 said:
It's really possible in this case,

This goes to the heart of my argument. I don't think Garmin wants to detect certain classes of warnings/errors on a case by case basis. I could be wrong though.

flocsy🤠 8 days ago in reply to FlowState

But they already do it. To give one example:

'$.Toybox.Application.AppBase.setProperty' is deprecated

vs:

Array.slice