What I think would be a nice addition to C# would be recognize return as a special keyword of throw, so that you can completely unwind the stack upto the point where UI entered and return a value without raising an exception. This would allow a user to start an async task, add a few continuations to this task, then "throw return" back to the top of the stack to the UI...without using the async keyword at all. Example:
void XYZ_Click(…) {
if (DeeplyNestedFunction() == 1) {
...
}
else {
...
}
}

int DeeplyNestedFunction() {
if (...) {
Task<Stuff> A = DoSomethingAsync();
Task C = A.ContinueWith((antecedent) => DoSomething2());
throw return; //return type matches
//top of stack "void" from XYZ_Click
}
else {
return DoSomethingNormalSynchronous();
}
return 0;
}

Now I can start an Error MessageBox without screwing around with async on every nested function....

int DeeplyNestedFunction() {
if (yourscrewedup) {
(new ContentDialog {
Title = "Really Bad Error",
Content = "you screwed up",
CloseButtonText = "OK"
}).ShowAsync();
throw return;
}
else {
DoSomething();
}
}

Right now there's basically three icons in the Class View/Object Browser: the Blue Icon, the Purple Icon, and the Beige Icon. ^^

Well, it's true that when you look closer, you can notice some differences in the shape. The enum icon shape is different from the class icon one or from the folder icon one. However, you need to look closer to see it. It's not something that strikes you in a quick look, and that makes navigating those views less useful.

I would say that a good usability test would be to blur the icons, and yet to be able to tell apart between them. Could you tell apart between them in the attached image?

There's a small problem when it comes to actions defined through lambda functions. I'm showing it in the screencap.

Let's say we have two methods: HellowWorld(), which returns a string, and DoNothing(), which doesn't return anything. There's no type safety problems when we use them through anonymous methods: Actions only accept anonymous methods that doesn't return any a value, while Func<string> only accept anonymous methods that return a string.

Now let's use lambda functions. No problem here with Func<string>: when the lambda function doesn't return a string, it shows an error, which it's OK.

The problem appears when you declare an action and assign some method that actually returns a value. Since lambda functions don't use the "Return" keyword, there's some ambiguity related to whether the output is used or dismissed. The action here considers that you can execute the method and dismiss the output. However, that's not really safe.

My suggestions: it could be useful to be able to enforce stricter type safety, either through IDE options or some pragma directive.

Why? Could that ambiguity create problems? Well, actually, it can. In my case it created a tricky bug and a nice couple of hours of debugging. I was passing a Func<string, Action> to a method that assigns Actions to UI elements. The API doesn't accept variables representing actions, so I had to do something like:

CreateUI(......, Func<string, Action> actions, ....)
{
___.......
___foreach(string s in UIKeys)
___{
______.......
______ApiAddListenerMethod(....,action: ( ) => actions(s),....);
______......
___}
___......
}

But the code is wrong. It's not assigning the action itself, but an action which returns the action itself. Tricky. Easy to fix, though, it's enough to change the parameter in the API method for: ( ) => actions (s)( ).

Would stricter type safety raise a warning here? It would, since the original action doesn't return any value, if you forget to add the additional "( )" then you would be trying to pass an action that returns an action, which wouldn't be accepted.

LINQ to SQL error reporting is currently implemented by generating random SQL with a clause 0 = 1 (usually in a WHERE statement.)
My understanding is this typically happens when there's an out of sync between the definition of a class in LINQ vs the actual entity in SQL.

I believe Microsoft's intentions were to return no results in this case, but the following issues arise by this implementation:

1) This is unintuitive to the developer, since generally no actual error occurs, just a change in the results being returned. The change in results being returned, could coincidentally be the correct result set the developer was intending too.

2) This doesn't always return no results, and in some cases returns all the results of the queried dataset or a filtered result set somewhere between none and all of the data.

Here's an example of LINQ's generated SQL query with the error reporting from a simple C# statement I wrote (also attached):

SELECT [t0].[ChildItemId] AS [item1], [t0].[ChildSerial] AS [item2]
FROM [dbo].[SerialDetails] AS [t0]
WHERE
(
(
CASE
WHEN [t0].[EndSerial] IS NULL THEN 0
WHEN 0 = 1 THEN
(
CASE
WHEN ([t0].[ParentItemModuleName] IS NOT NULL) AND (UPPER([t0].[ParentItemModuleName]) = NULL) THEN 1
WHEN NOT (([t0].[ParentItemModuleName] IS NOT NULL) AND (UPPER([t0].[ParentItemModuleName]) = NULL)) THEN 0
ELSE NULL
END
)
ELSE 1
END
)
) = 1

-- @p0: Input Int (Size = -1; Prec = 0; Scale = 0) [0]
-- @p1: Input VarChar (Size = 8000; Prec = 0; Scale = 0) [Null]
-- @p2: Input Int (Size = -1; Prec = 0; Scale = 0) [1]
-- Context: SqlProvider(Sql2008) Model: AttributedMetaModel Build: 4.7.2046.0

As you can see, the 0 = 1 clause ended up in a subquery inside the WHERE statement as part of a CASE statement and therefor doesn't actually end up getting hit. This means the instead of no results coming back, I get a different set of results, and have no indication that there was an error generating the SQL.

An actual runtime error being thrown (which could come from the LINQ to SQL class) would be so much better than just taking a gamble by generating a 0 = 1 clause and then returning a result set.