Discussion: lock and using expressions

[alrz]

var res = lock (obj) M();
var res = using (var x = e) x.M();

instead of

string res;
lock (obj) { res = M(); }
using (var x = e) { res = x.M(); }

This lets you use type inferred locals which can also be made readonly (#188).

let res = lock (obj) M();
let res = using (var x = e) x.M();

[aluanhaddad]

using👍
lock 👎

[alrz]

@aluanhaddad Any reasons why?

[CyrusNajmabadi]

I would def find value in a lock-expression.

[jnm2]

I've thought about lock expressions a lot recently. Using expressions not so much.

[FunctionalFirst]

You could take a page out of the F# playbook and do something like this:

static T Lock<T>(object syncObj, Func<T> fn) {
    lock (syncObj) {
        return fn();
    }
}

var obj = new object();
var res = Lock(obj, M);

[jnm2]

As long as that is the only time in your career where you invoke a delegate inside a lock statement, I promise not to have a heart attack. 😁

[FunctionalFirst]

@jnm2 How is that any different than lock(obj) M();?

[jnm2]

@FunctionalFirst Your code sample is fine! I'm wary of delegates inside a lock in general. It can lead to reentry issues or deadlocks in corner cases depending who gave you the delegate. For example, the delegate might raise an event.

[aluanhaddad]

@alrz

@aluanhaddad Any reasons why?

Now that I think about it, I don't know, both seem reasonable. I just feel like locks should be very rare and don't need a sugar.

[frederik-h]

One place where I really miss lock expressions is in expression bodied properties. I use those a lot, but it is not possible whenever I need to use a lock. I would like how lock expressions would make the code style more consistent.

[GeirGrusom]

Inconsistency is a bad trait of any programming language. If it works for using it should work for lock as well simply because it would be odd if it didn't.

[jnm2]

@GeirGrusom I used to think that, but I'm not actually sure why that's really an important factor anymore.

[GeirGrusom]

I hate stumbling upon things that don't work simply because it doesn't. SQL dialects are filled to the brim with those, and encountering inconsistencies doesn't exactly brighten my day. I never say "Oh how wise of the language designers to make that inconsistent with the language syntax". More commonly it makes me talk trash about that language at the water cooler.

[jnm2]

@GeirGrusom throw default is disallowed for example. unsafe can go in member and type declarations, but checked cannot. It's a matter of perspective; I'd say there's such a thing as a good inconsistency when the inconsistency puts friction in the right place like throw default. I'd have the same opinion about an expression form of lock; I think there should be friction to to encourage you to avoid having a lot of simple members that lock.

[alrz]

there should be friction to to encourage you to avoid having a lot of simple members that lock.

I don't think that's useful. convinience in doing so when you need it isn't harmful and the "friction" wouldn't help you to overcome the requirement.

consider this example:

lock(o)
  M(CriticalMethod(), M());

here you have held the lock for uncritical sections as well. either you need to manually capture the result in a local,

int result;
lock (o)
  result = CriticalMethod();
M(result, M());

or have the compiler generate it for you,

M(lock (o) CriticalMethod(), M());

so you release the lock as soon as you're done with it without adding any complexity to the flow of the code.

[Joe4evr]

unsafe can go in member and type declarations, but checked cannot

We need to bring back support for #552.

[jnm2]

Hehe #552 (comment)

[Joe4evr]

I know, that's why I said we. 😆

[HaloFour]

@alrz

You're last example doesn't work unless lock (x) expression is also considered an expression, which is a bigger change to the language than just allowing the removal of the braces, and would be quite inconsistent with the rest of the language.

[alrz]

You're last example doesn't work unless lock (x) expression is also considered an expression,

that's what this issue is about.

than just allowing the removal of the braces

it's already allowed. (it uses an embedded-statement)

would be quite inconsistent with the rest of the language.

how?

[HaloFour]

@alrz

that's what this issue is about.

Oh yeah. Sometimes one gets wrapped up in a new set of comments that you forget what the original proposal was about.

would be quite inconsistent with the rest of the language.

how?

How many other control statements in the language followed by an embedded statement are expressions or can be expressions?

[alrz]

How many other control statements in the language followed by an embedded statement

This would be a completely separate syntax form, just like #101 (btw, lock and using are not a control statement.)

[svick]

@HaloFour

How many other control statements in the language followed by an embedded statement are expressions or can be expressions?

There is a precedent for having an expression version of that kind of statement: ternary expression for if statement and now switch expression for switch statement (though that one is technically not an embedded statement).

In both those cases, the expression version has different syntax than the statement version, but I don't think there's a reason for that here.

The language is moving to be more expression-friendly and this would be another step in that direction.

[alrz]

with introduction of switch expressions, the need for something like "block expression" is more visible. while switch expressions and :? have specialized syntax and are extremely common, for others I think we don't need a new syntax form, we should just be able to wrap statements inside some kind of "block expression".

[lostmsu]

@HaloFour is there a scenario when it is hard to disambiguate using(x) ... statement from expression?
When parsing statements seeing a using token in the beginning means statement otherwise it would always be an expression.

[CyrusNajmabadi]

otherwise it would always be an expression.

A core problem is that 'otherwise' case comes up a lot during editing :)

[lostmsu]

@CyrusNajmabadi are you saying it would slow down typing performance in IDE around using keyword?

[CyrusNajmabadi]

It's not a matter of perf. It's a matter of ambiguity and error recovery during editing scenarios.