Acknowledged
5 months ago
CIQQA-3064

Compiler warns about deprecated symbol even when building for device where symbol is not deprecated

e.g.


// in entry point class that extends appbase

var val;
if (Toybox.Application has :Properties) { 
  // ciq >= 2.4.0 
  val = Application.Properties.getValue("foo"); 
} else { 
  // ciq < 2.4.0
  val = AppBase.getProperty("foo"); // compiler warns that AppBase.getProperty is deprecated
}

Regardless of what device this code is built for, the compiler will warn that AppBase.getProperty is deprecated. I would argue this is confusing and misleading because:

1) getProperty is not deprecated for devices with CIQ < 2.4.0. In fact, for those devices getProperty is *required*, if you want to read persisted data

2) Even for devices with CIQ >= 2.4.0, the warning may be confusing because it still implies that your code is wrong because it calls that function (even though as written, it will never be called for those devices.)

Here's an example of where the deprecation warning may have led to confusion (or not, it's hard to say):

(it's a deprecation warning triggered by an SDK sample which correctly shows code which can run on both older devices and newer devices, using old deprecated enums for older devices, and new non-deprecated enums for newer devices)

https://forums.garmin.com/developer/connect-iq/i/bug-reports/bug-documentation-typos-in-toybox-position-enablelocationevents-example

Nonetheless, the issue of the deprecation warnings has come up many times in the forums.

I realize this is sort of a no-win situation here. I don't have any good suggestions for fixing it. But I do think there needs to be a way for the compiler to convey that code which uses deprecated symbols *may* be correct after all.

flowstate
Parents
  • 13 days ago

    More details:

    This is never going to happen, but it would be great if the Monkey C compiler supported conditional compilation / runtime checks based on literal CIQ API level, in such a way that the compiler understands what version is being targeted. Simply getting the CIQ version at runtime via an API call is not sufficient - it has to be a construct that the compiler understands and controls, so that it can make decisions based on which version is being targeted. This goes beyond minApiLevel, as it would allow for different code to be include / excluded or executed / not executed based on *differing* CIQ API level amongst app targets.

    Not to be an Apple fanboy, but let's say your iOS app targets devices iOS 16, 17, and 18. If you call a function which is available starting in iOS 18, then the compiler *forces* you to add a runtime check along the lines of "if @available[ios18]" around the code. This enforces both the desired source code documentation and runtime behaviour: the code in question only runs on ios 18, so it's impossible for it to crash on ios 16 or 17 because it won't run. Apple implements both compile-time macros - if #available - and runtime checks - if @available - to select different code based on platform version.

Comment
  • 13 days ago

    More details:

    This is never going to happen, but it would be great if the Monkey C compiler supported conditional compilation / runtime checks based on literal CIQ API level, in such a way that the compiler understands what version is being targeted. Simply getting the CIQ version at runtime via an API call is not sufficient - it has to be a construct that the compiler understands and controls, so that it can make decisions based on which version is being targeted. This goes beyond minApiLevel, as it would allow for different code to be include / excluded or executed / not executed based on *differing* CIQ API level amongst app targets.

    Not to be an Apple fanboy, but let's say your iOS app targets devices iOS 16, 17, and 18. If you call a function which is available starting in iOS 18, then the compiler *forces* you to add a runtime check along the lines of "if @available[ios18]" around the code. This enforces both the desired source code documentation and runtime behaviour: the code in question only runs on ios 18, so it's impossible for it to crash on ios 16 or 17 because it won't run. Apple implements both compile-time macros - if #available - and runtime checks - if @available - to select different code based on platform version.

Children
No Data