Personalized Community is here!
Quickly customize your community to find the content you seek.
Now Available in Community - New TechTalk Videos for 2020
Read More about New TechTalks for 2020
2020 Release Wave 2Discover the latest updates and new features to Dynamics 365 planned through March 2021.
Release overview guides and videos Release Plan | Preview 2020 Release Wave 2 TimelineWatch the 2020 Release Wave 1 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
Every now and then we have to introduce a fix to the X++ compiler, either for code or metadata validation. In many cases we introduce them as compile warnings (instead of errors) to avoid too much disruption, but sometimes we feel the mistake we're detecting is too important and a compile error is introduced. Since these fixes are typically done because we actually found an issue, it implies there is at least 1 customer that may find a compiler error in the future - correctly pointing out a problem in their code or metadata. Today I want to point out such an upcoming fix in the X++ compiler which will be brought in as an error, regarding the ternary operator ( expression ? trueexpression : falseexpression ) when used with enums.
Consider the following example:
MyEnum me = DifferentEnum::Value1;
In this case, the compiler will detect that you are trying to assign essentially the wrong type to your enum and will give you a compile error. Now, let's try the same mistake, but inside an expression using the ternary operator:
MyEnum me = (someExpression) ? DifferentEnum::Value1 : DifferentEnum::Value2;
In this case, the compiler is currently evaluating all the types here as integers (not enums), and it will not complain but rather compile without error. Clearly this is wrong. If enums are extensible, it may be even more problematic if this code is present, due to the nature of values of extensible enums.
This is expected to be included in a GA update somewhere after the April GA of PU33, and the above example will result in a compile error as of those versions, as it should. This of course means that any code that has this mistake in it, will no longer compile cleanly. Import to note that code already deployed (=compiled) will continue to run since this is a compiler-check only. Our runtime compatibility promise is something we cannot and will not break.
Business Applications communities