Topics

Featured in Development

Peter Alvaro talks about the reasons one should engage in language design and why many of us would (or should) do something so perverse as to design a language that no one will ever use. He shares some of the extreme and sometimes obnoxious opinions that guided his design process.

Featured in AI, ML & Data Engineering

Today on The InfoQ Podcast, Wes talks with Katharine Jarmul about privacy and fairness in machine learning algorithms. Jarul discusses what’s meant by Ethical Machine Learning and some things to consider when working towards achieving fairness. Jarmul is the co-founder at KIProtect a machine learning security and privacy firm based in Germany and is one of the three keynote speakers at QCon.ai.

Featured in Culture & Methods

Organizations struggle to scale their agility. While every organization is different, common patterns explain the major challenges that most organizations face: organizational design, trying to copy others, “one-size-fits-all” scaling, scaling in siloes, and neglecting engineering practices. This article explains why, what to do about it, and how the three leading scaling frameworks compare.

The current word is that tuple names in generic constraints cases simply aren’t going to be checked by the compiler. Theoretically the compiler could catch stuff like this, but the performance cost would be too great compared to the benefit.

Pattern-matching with Generics

Pattern matching, new in C# 7.0, has a design flaw when it comes to generics. Consider this code submitted by Alex Wiese:

This gives us the error: “An expression of type T cannot be handled by a pattern of type KeepalivePacket.” But if we change the parameter to be of type System.Object instead of T, it works as expected.

We change the paragraph in the pattern-matching specification (the proposed addition is shown in bold):

Certain combinations of static type of the left-hand-side and the given type are considered incompatible and result in compile-time error. A value of static type E is said to be pattern compatible with the type T if there exists an identity conversion, an implicit reference conversion, a boxing conversion, an explicit reference conversion, or an unboxing conversion from E to T, or if either E or T is an open type. It is a compile-time error if an expression of type E is not pattern compatible with the type in a type pattern that it is matched with.

This is considered to be a bug fix, but since it will “introduce a forward incompatibility” you will have to set the compiler to C# 7.1 in order to take advantage of the change.