Assignment using Ternary Operator

Couple of days back, I happened to come across a question in StackOverflow. Question seemed pretty straightforward, but at the same time, interesting. How would one use ternary operator for assignment. For example, how would write following code using ternary operator.

var a = 1;
var b = 2;
var c = 3;
var flag = false;
if(flag)
a = c;
else
b = c;

Obviously, following wouldn’t work.

// CS0131 The left-hand side of an assignment must be a variable, property or indexer
(flag?a:b) = c;

One way to use ternary operator would using Action.

(flag ? new Action(() => a = c): () => b = c)();

But that doesn’t quite give you the clean syntax of Ternary Operator. That brings us to the second way using features exposed by C# 7.2. Let us rewrite the code.

(flag ? ref a : ref b) = c;

Enjoy coding…

C# 7.3 Features : Tuple Comparison & Generic Constraints

C# 7.3 is another minor roll-out that brings along with ‘seemingly minor’ improvement, but ones that definitely opens new opportunities. In this blog post, we will explore  two features that are introduced in 7.3

Tuple Comparison

C# 7.x had already made tuple an immensely powerful tool with a variety of features, and the latest minor roll-out takes that a step higher. Prior to C# 7.3, we could not use ‘==’ and ‘!=’ operators to compare tuples. C# 7.3 improvements makes it possible for us to do the same.
var tuple1 = (3,4);
var tuple2 = (5,6);

if(tuple1 == tuple2)
{
// Do something
}

Generic Constraints

The way I see it, this might turn out one feature which find more fans.  Generics, since its introduction in C# 2.0, was always handicapped by its in ability to constraint the accepted generic type must be an enum.
void TestMethod(TSource param) where TSource : Enum
{
// Do something
}
C# 7.3 also allows you use following constraints
  • unmanaged
  • delegate
That’s it for now, we will explore more features soon.

Type Casting using Span<T>

In an earlier post, we explored the possibilities of Span and performance benefits of the feature was clearly visible in our benchmark tests. We will continue exploring the Span further in this post, as attempt to cast between types using Span.

The cast functionality is not that hard, thanks to the extension methods that comes along with Span<byte> under the System.MemoryExtensions namespace. The NonPortableCast method converts a Span<byte> to the specified Type.  As seen in the code below, the first step however is to convert the original type to a byte array. The implicit conversion between byte array and Span<byte> would allow you to convert it to Span<byte>.

 

long originalPrimitiveType = 25;
Span byteSpan = BitConverter.GetBytes(originalPrimitiveType);
Span intSpan = byteSpan.NonPortableCast();
int castPrimitiveType = intSpan[0];
The key point to note here is the first 4 bytes of Span<byte> maps to the zeroth element of Span<int>. The code samples described in this post is available in my Github.

Deconstructing Non-Tuples

The ‘Tuple evolution‘ in C# 7x has created increased possibilities of C# like never before, both in terms of performance as well as readability. One of the nicest feature that came along has been the Deconstruction of tuples.

Deconstructing Tuples

The tuple data structure allows us to bundle together a finite number of values without having to go through the pain of creating a dedicated Data structure for it. This is often useful when we need to return more than one values from a method. Consider the following method.

private Tuple GetPerson()  =>  new Tuple("Jia", 2);

Prior to C# 7, this is where the fun ended. While it was easier to return multiple values from a method, it was a tedious task to read those data.

var person = GetPerson();
Console.WriteLine(person.Item1);
Console.WriteLine(person.Item2);

As you can see, this resulted in the code readability hitting rock bottom. But C# 7.0 has changed the picture completely and has made the Tuples not just more powerful, but extremely easy to use. Let’s rewrite the method as well as the caller access in C# 7.x.

private (string,int) GetPerson() => ("Jia",2);
var (name,age) = GetPerson();
Console.WriteLine(name);
Console.WriteLine(age);

As evident from the code, the readability and ease to use has increased, and that is not limited to just the caller. Even the way we return the method signature and return statement has become far more simpler.

Deconstructing Non-Tuples

The whole deconstruction process has made usage of tuple so flexible. What if we could leverage the same functionality in the non-tuples data structures ? Consider the following class.

class Person
{
  public string Name { get; set; }
  public int Age { get; set; }

  public Person(string name,int age)
  {
    Name = name;
    Age = age;
  }
}

private Person GetPerson() => new Person("Jia",2);
var person = GetPerson();

Of course it is easy to access the Name/Age Properties using the person.Name, person.Age syntax. But there could be situation when the Person class has many other properties and you are interested only in just a couple. Or there could be another situation when you want to assign the Name and Age properties directly to existing variables in the caller method. In such scenarios, we would have to write the following code.

// where 'name' and 'age' are variables in caller method.
var person = GetPerson();
name =  person.Name;
age  = person.Age;

C# 7.0 has made life things easier with the Deconstruct for non-tuples. All we need to do is add a simple Deconstruct method to the Person class.

public void Deconstruct(out string name, out int age)
{
  name = Name;
  age = Age;
}

The parameters of the Deconstruct method needs to be out parameters. That’s all you need to do for deconstruction of non-tuples to be effective. The code in question could be now rewritten as following.

(name,age) = GetPerson();

C# 7.x is turning out to be an interesting evolution of C# language. Eagerly waiting to see what is in store for C# 8.0.

Nominal Vs Structural Type System

Anonymous Types and Tuples might look very similar, but there is one significant difference which separates them. As always, nothing can be more explanatory than writing code.
var anonymous1 = new { x = 1, y = 1 };
var anonymous2 = new { y = 1, x = 1 };

var tuple1 = (x : 1, y : 1);
var tuple2 = (y: 1, x: 1);

Console.WriteLine($"Anonymous Type :  {anonymous1.Equals(anonymous2)}");
Console.WriteLine($"Tuple Type : {tuple1.Equals(tuple2)}");
Consider the above code. What could be the output ? Are both false or are both true ? Interestingly, the output is as follows.
Anonymous Type : False
Tuple Type : True
Though syntactically similar, both Anonymous Types and Tuples vary in a significant factor – the associated type system.  While Anonymous Types is based on Nominal Type System, Tuple is based on Structural Type System. This results in the behavior seen in the above code, with both tuples being equal despite the obvious naming pattern difference.
That brings us to another scenario, what if the sub types for tuples are differently named. For example, consider following code.
var tuple1 = (x : 1, y : 1);
var tuple3 = (a: 1, b: 1);
Console.WriteLine($"Tuple Type : {tuple1.Equals(tuple3)}");
As you would have rightly guessed, the output would be “true” as the tuple is only interested in the types and not the names.

Benchmarking Span<T> Performance

Span<T> is yet another addition to C# 7.x and is particularly useful in developing memory intensive applications.  So what is Span all about ?

 

As Microsoft describes it, Span<T> is a new value Type which enables the representation of contiguous regions of arbitrary memory, regardless of whether the memory is associated with a managed object, is provided by native code  or is on the stack, with a performance characteristics like that of an array.

 

It feels like you can use pointers, but without entering ‘unsafe’ code. That definitely is interesting. We will be looking into Span<T> closely in upcoming posts, but for this post, we will compare Span with Strings when parsing sub strings.  We will begin by how sub strings work. We will keep it simple for sake of the example. Consider the following code.
public void DummyMethod(string data) { }

string keyString = "234567";
DummyMethod(keyString.Substring(0, 2));
DummyMethod(keyString.Substring(2, 2));
DummyMethod(keyString.Substring(4, 2));

Remember string is immutable, and each time we are invoking the Substring method, we are allocating a new memory location is allocated with the substring. Now that isn’t a scenario you wouldn’t want to be if you are working on a memory intensive application and you want to parse a really long string. But what is we could parse the string right from the memory location allocated for keyString. That would be extremely efficient right ?

That’s where Span<T> comes in. It would allow us to point to a contiguous region of memory, and allow us to parse through it without needing a different memory allocation. Let’s rewrite the above code using Span<T>.

public void DummyMethod(ReadOnlySpan data) { }

ReadOnlySpan keyString = "234567".AsReadOnlySpan();
DummyMethod(keyString.Slice(0, 2));
DummyMethod(keyString.Slice(2, 2));
DummyMethod(keyString.Slice(4, 2));

Notice that the string has a nice little extension method to create a ReadOnlySpan. We are also using the Slice method (instead of Substring) to access the specific part of memory location. We will do a bit of bench marking to understand the performance implication. Let’s create a BenchmarkDemo Class for our demonstrative purpose. Complete source code is available at my Github.

[Benchmark]
public void UsingSubString()
{
    string keyString = "long string";
    for (int i = 0; i < IterationLimit; i++)
        DummyStringMethod(keyString.Substring(0, i));
}
void DummyStringMethod(string _) { }

[Benchmark]
public void UsingSpan()
{
    ReadOnlySpan keyString = "long string".AsReadOnlySpan();
    for (int i = 0; i < IterationLimit; i++)
        DummySpanMethod(keyString.Slice(0, i));
}

void DummySpanMethod(ReadOnlySpan _) { }

The above code is for demonstrative purpose, hence we are using a dummy string "long string". In the example in Github, you can find the same replaced with lorem ipsum.

Alright, now lets run the Benchmark code and analyse the memory allocation against iteration loops of 10,100, and 400. We are using BenchmarkDotNet for example.

Benchmark Span

As you can see the “UsingSubString” method uses a huge amount of memory as the calls to substring increases. On other hand, Span based method hardly uses any and doesn’t have any different as the number of calls increases.

That’s it for now, we will investigate more on Span<T> in upcoming posts.

Ref Value Type

In an earlier post, we discussed the readability factor of the reference semantics, mentioning how it kind of makes the code less readable. However, that doesn’t take away the big door of opportunities the new features add. Consider the following scenario.

As a developer, you want to develop a extension method called Increment
for Type "int", which increments the value by 1.
The extension method should have a void return type.
We would ideally would like to do the following.

int testValue = 1;
testValue.Increment();
Console.WriteLine(testValue);   // This should print a value 2;

Now, prior to C# 7, this was difficult. There was no way we could pass a reference of a value type to an extension method. Which means that every time we call the extension method, we would be passing a copy of the value, rather than the reference, increment the copied value and then just throw away the value. The above code would print a value “1”.

This is where the new reference type comes in play. We could now use reference type in extension methods. Let’s write the code using C# 7 now.
public static int Increment(this ref int Val) => ++Val;
Now if we were to run our code, testValue would show a value “2” as desired. That’s interesting right ?.  Of course, there are other befits too. Consider the scenario where you have a gigantic struct (it is another question whether it is ideal to use a value type when the type is expected to be huge, but for sake of the demonstration we will use struct here) which gets passed to different methods. Each type you are calling the method, you are creating a copy of the gigantic struct (allocating memory).  This is going to be troublesome if you are working on a memory critical environment and the struct is going to be passed around.
With C# 7.0, you can not just pass the value type as reference, but we can also return a value type as ref. That is just brilliant by the language developers right. Let’s go ahead and look into the syntax of the same by modifying our extension method so that it returns a reference as well.
public static ref int Increment(this ref int data)
{
++data;
return ref data;
}

int testValue = 1;
ref int pointsToTestValue = ref testValue.Increment();
Console.WriteLine(testValue);
pointsToTestValue++;
Console.WriteLine(testValue);

The Increment method increments the value as it did earlier. Furthermore it now returns the same value as reference. Do note the changes in syntax for invoking as well as defining a method that return ref.

The output of above code would be

2
3

There might be scenarios where you might have to pass a data as reference, but ensure it doesn’t change. Here is where the new ‘in’ parameter comes in. The “in” keywords accepts the data by reference, but ensure that a developer who works on in future doesn’t change the value accidentally. “in” can be used in interface as well, to ensure that the implementing classes doesn’t change the value in the method.

public int Increment(in int data)
{
++data; // this is not allowed
return data;
}
Update : 
You could also make a returned reference read only, though we would go back to using the readonly keyword rather than “in”. (makes sense too). The syntax would be as follows.

 

static public ref readonly int Increment(ref int data) => ref data;

ref readonly int readonlyReference = ref Increment(ref h);
readonlyReference++; // This is not allowed.

One obvious question of having a reference return type would be , what happens to the scope ? Does that mean GC needs to be aware of references outside scope of a method ? Not exactly, the Language team has thought well about it and has implemented certain safety constrains. The method can only return a ref that either came as a parameter or are in same heap. You cannot return a reference that is created within the method.

We will cover some more features of C# 7.x in coming posts, especially the ones that has to do with reference semantics.