C# 7.0 – an X++ developer’s dream coming true?


 

Today I attended an excellent TechTalk on C# 7.0 by Mads Torgersen at a full house in Microsoft Development Center Copenhagen.

 

As the talk unfolded I was struck by Déjà vu– this is not the first time I’ve heard Mads present a new feature in C#, that I’ve been using for a long time. Last time it resulted in two blog posts:

 

This time Mads presented a handful of new features, 3 of which X++ already has. Granted, the X++ variants of these are not as powerful, and not as complete. Yet, the intentions are the same:

  1. Inline functions
  2. Multiple return values from a method
  3. Deconstruction

 

Here are two implementations using these capabilities – one is X++ one is C#. Can you spot which is which?

public void foo() 
{  

    var arr = new int[] {4, 8, 15, 16, 23, 42};  
    int s, c;  
    (s, c) = this.tally(arr);
}
private (intint) tally(int[] arr) 
{  
    int c, s;  
    void add(int v) 
    {  
        c++;  
        s+=v;  
    }  
    foreach(var v in arr) 
    {  
        add(v);  
    }  
    return (s, c);  
}  

public void foo() 
{  
    var arr = [4, 8, 15, 16, 23, 42];  
    int s, c;  
    [s, c] = this.tally(arr);  
}  

private container tally(container arr) 
{  
    int c, s;  
    void add(int v) 
    {  
        c++;  
        s+=v;  
    }  
    for (int i = 1; i <= conlen(arr); i++) 
    {  
        add(conpeek(arr, i));  
    }  
    return [s, c];  
}  

 

As you may have read in my series of blog posts on X++ in AX7, it is obvious that X++ is moving in the direction of C# – seeing C# moving in the direction of X++ is not something I had seen coming – but it is very welcome!

Comments (8)

  1. Douglas Noel says:

    Will the exeption handling adjusted during further movement to c#?

    Any possibilities to catch CLR standard exceptions in all cases independent of the TTS transaction level?

    Some kind of determined handling without knowing the sorroundings/usage. Something like finally, which is always triggered but for the catch part. Like c# handling?

    Or will this ‘special’ undetermined x++ handling stay forever?

    1. Thanks for the comment Douglas.

      X++ is constantly improving. Take a look at my blog post of the new X++ features in AX7 here: https://blogs.msdn.microsoft.com/mfp/2016/02/08/what-is-new-in-x-in-ax7/
      This includes support for “finally” – just like we know it from C#.

      Right now there are no plans to support catching more exception types inside transactions. Currently UpdateConflict and DuplicateKey exceptions can be caught.

      Best regards,
      Michael

      1. Douglas Noel says:

        Hi Michael,

        it seems that even the handling of UpdateConflict and DuplicateKey exceptions cannot be handled inside a transaction in the meanwhile after the newest platform update of D3FO.

        So you can’t handle any exception within a transaction at the moment. Is this right? Will this be the final state of exception handling?

        Kind regards

        Douglas

      2. Hi Douglas,

        In the latest Platform update you can no longer catch duplicationKey and UpdateConflict in a *Catch-All* statement inside a transaction. Or in other words: To catch these two exception types you must be explicit, for example: catch (Exception::UpdateConflict).

        For more information see:
        https://blogs.msdn.microsoft.com/mfp/2016/11/24/x-the-catch

        Thanks,
        Michael

  2. Logger says:

    Hi.
    Do you plan to fix X++ logical operations priority ?

    C# : A || B && C is equivalent A || (B && C)
    X++ : A || B && C is equivalent (A || B) && C

    It is very insidious feater. (This prevents X++ to be similar to C#)
    So, I always use parenthesis to avoid disambiguate.

    1. Thanks for noticing this idiosyncrasy of X++ and for pointing out how to be on the safe side.
      Changes like what you suggests are simple to make in the compiler, but has a devasting impact on X++ code across the planet. So it is not something we will (or can) change.

      Over the releases we have introduced breaking changes to the language; which is not something we take lightly. In certain cases we have accepted breaking changes that were tightening up the language; and any no-longer-supported code would be detected by the compiler. While it can be painful to upgrade to the new compiler/syntax it is also a low risk and mundane task. The change in operator’s priority is of a different nature. The syntax is still valid, the code just behaves differently. If we could rewind the clock 20 years, we might be able to get away with such a change without getting flogged.

  3. Stefan says:

    Typo on the left side ? cnt should be c ?

Skip to main content