Hacker News Reader

Comment by Someone1234 | Hacker News Reader

I like the feature, don't love the boilerplate.

If C#/.Net was invented today you could just implicitly have access to this information from within your function's scope. The compiler is smart enough to figure out if the CallerArgumentExpression() is used and optimize away the ones which were not.

nameof was added in C# 6, this like that, could have been added too e.g.: $"arg: {nameof(thing)}, with value: {thing}, from caller's: {callerargumentexpression(thing)}". It is a very useful logging/diagnostic tool, but I'd have to throw CallerArgumentExpression("") all over my code just-in-case, and I hate that.

PS - Yes I read the whole article, and understand how useful it will be for asserts/specific tooling; my point is that their imagination was too small and this will creep into all kinds of code.

View on HN

> I like the feature, don't love the boilerplate.

It's not for you, though. The boilerplate is for a very small number of libraries and frameworks that have use for this feature. The ergonomics of using the resulting methods from these libraries and frameworks are quite good.

This is just like the CallerMemberName attribute.

> It's not for you, though.

It is "not for me" though because of the reason I said: Too much boilerplate for common usage. If it had less it would be for "me" and everyone else too, just like the nameof() is.

So it is a niche tool exactly because of the implementation. I bet a lot of people expected nameof() to be niche too, but it isn't.

No, it's a niche tool because it's a niche tool. This feature has very limited use; even more limited than CallerMemberName. It actually makes a lot of sense not to invent a lot of new syntax or compiler logic to handle something this rarely used.

agreed, if they made it to be eg. expressionof() - which to be fair might happen in the future - then it would be just as usable as nameof()

It's not that their imagination is small, it's that the designers of a language as popular as C# have to be cautious: not only they must not break tons of existing code, but they must also not introduce features that end up not being used because they're poorly designed (but still have to be supported for the same backwards compatibility reasons).

Thus it's not uncommon for C# to add things like these: they are small and easily defined, solve a specific but very common use case, and are much easier to put on life support in the future if something better comes along. It's not "neat", but practicality beats purity.

Having led the creation of a language/compiler professionally, the number of features that are "nice to have" are nearly infinite. And occasionally a lower priority item that was easier to implement at the time, become far larger in scope because of how another higher priority feature was implemented. Some of these can get scrapped or pushed back till the cycles allow it.

Often though, we learn in the implementation, and some of the lower priorities are no longer needed. And Reflections provided a lot of the functionality that you could make seamless from a parent class and attributes.

I agree with you about the `nameof` comparison, mainly because it deceptively looks like something you'd be able to write yourself (since it's just an attribute), but under the hood it's compiler magic. I'd rather it be more like a keyword or obvious language built-in so there's a clearer boundary between "this is a language feature" and "this is a standard library feature".

Reply on news.ycombinator.com