Posts Tagged ‘C#’

Suggestion: add optional “where” clause to “foreach” statement in C#

Wouldn’t it be nice if I could use in C# the following syntax?

for (SomeType repeaterVariable

      in SomeEnumerable

      where someBooleanExpressionOfRepeaterVariable)


e.g. use this one:


instead of this one:


BTW, if you wonder what FixTime does, it prepends 0: to time strings to make sure they are of format h:m:s.f

Have added this as a comment to another person’s suggestion that I see has similar format, so please vote for that one:

Categories: Posts Tags: , , , , ,

Suggestion: Add instance modifiers to C# (and other languages)

I’d like to be able to do

someFunctionReturningY(x){ somePropertyOfY=4; … }.DoSomething();

It should also support casting without needing parentheses in the following type of statement:

Z zzz = (Z)functionReturningY{somePropertyOfZ=…; … };


The same pattern should work for enums too apart from object instances. It is inspired by initializers in C#, e.g. var x = new Test(){someProperty=…}. It’s just a generalization of the same pattern.

E.g. at the following scenario I want to modify an object that GetMetadataFromUI function returns



and currently I’m forced to write this which is way more verbose:



If you like this suggestion please vote for it at:

Suggestion: If and while etc. clauses should accept bool? in C#

At TrackingCam app ( I have the following WPF code, where cbTrackingPresenter is a CheckBox control defined in my MainWindow’s XAML:

private void cbTrackingPresenter_Checked(object sender, RoutedEventArgs e)
      if (cbTrackingPresenter.IsChecked == true)

Note the (redundant in my opinion) == true pattern used there. If the == true is omitted, you get the compile-time error "CS0266", with message "Cannot implicitly convert type ‘bool?’ to ‘bool’. An explicit conversion exists (are you missing a cast?)"

Why not make the "if" clause (and "while" and any clause accepts a boolean/condition) more clever and have it accept bool? too? It would only fire the condition if the value is "true" (not if it is false or null) in that case.

You can vote for this suggestion at:

HowTo: show inner exception message if available, else outer one

Sometimes when you catch an exception in .NET, the message it prints out isn’t very informative, since it is wrapping another exception that had been thrown a bit inner in the code. That exception is in that case accessible via InnerException of the Exception instance.

That inner exception is also an Exception, so one would like to use its Message instead of the outer exception’s one, if an inner exception exists and, only if an inner exception doesn’t exist use the caught exception’s message. Here’s a clean-looking pattern I’ve coined up to achieve this while working on the TrackingCam application:





catch (Exception e)


  MessageBox.Show((e.InnerException ?? e).Message);


the ?? operator returns e.InnerException if it is not null, else falls back to returning e. Those two results are both of type Exception, so you can use Message on them, by putting the ?? operator’s expression in parentheses.

Suggestion: C# static extension methods invokable on class type too

it would be nice if C# supported syntax like:

public static DependencyProperty Register(static DependencyProperty x, string name, Type propertyType, Type ownerType, FrameworkPropertyMetadata typeMetadata)

that is static extension methods for classes, that can be invoked without a class instance (just with the class type), apart from normal extension methods that can be invoked on a class instance.

Then for example I could use it in Silverlight to add to its DependencyProperty class some extra WPF syntax that it currently misses, in order to increase code portability. It would wrap Dr.WPF’s implementation of value coercion for Silverlight’s DependencyProperty. I have the related code at my Compatibility library ( and respective NuGet package (, but the syntactic sugar is missing to achieve source code portability (via WPF and Silverlight projects that include common files via file links) without changes.

Note the "static DependencyProperty" parameter instead of the "this DependencyProperty" one that is used in C# extension methods (or else instead of static maybe they could use other keyword like type or typeof there, but I feel static is more appropriate).

Related discussion:

Also see where somebody mentions "static extension properties" apart from "extension properties". Indeed it is natural that if static extension methods are to be allowed in the future, static extension properties should be added too (to extend a type with [attached] static properties)

You can vote for a related suggestion here:

Suggestion: Initialize multiple fields to same value at constructor call in C#

When using I would like to write:

FloatingWindow window = new FloatingWindow()
  Content = display,
  Title = IconText = title

but I have to write:

FloatingWindow window = new FloatingWindow()
  Content = display,
  Title = title,
  IconText = title


instead. For consistency, I’d prefer that it supported such assignment. Now it thinks IconText is some external field or similar


you can vote for this suggestion at:

%d bloggers like this: