Timeline for Why can't Java/C# implement RAII?
Current License: CC BY-SA 4.0
27 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Jul 28, 2020 at 11:16 | history | suggested | Metallkiller | CC BY-SA 4.0 |
Added update to clear up keyword
|
| Jul 28, 2020 at 11:13 | review | Suggested edits | |||
| S Jul 28, 2020 at 11:16 | |||||
| Jul 3, 2019 at 8:06 | comment | added | Konrad | @AvnerShahar-Kashtan makes sense. | |
| Jul 3, 2019 at 8:02 | comment | added | Avner Shahar-Kashtan | @Konrad that's because it doesn't exist - I proposed it as an alternative solution to the OP's suggestions. However, in the years since I made it, C# did add this ability with C# 8's using declarations | |
| Jul 3, 2019 at 8:00 | comment | added | Konrad |
@AvnerShahar-Kashtan can you tell me where did you find it? I can't find local keyword description in the C# docs.
|
|
| Oct 31, 2013 at 3:57 | comment | added | redtuna | I like this idea, though I'm not super-fond of the word "local". It's personal of course, but I'd suggest the word "scoped" instead. To me this gives a hint that something may happen that's related to the scope - and indeed, we're calling Dispose at the end of the scope. | |
| Oct 30, 2013 at 21:32 | comment | added | mike30 | @RobertHarvey. The definition of sugar is ambiguous, but using-blocks are nothing more than a syntax expansion to try-finally-dispose. The fact it requires a compiler change does not make it non-sugar. Unless your programming in lisp, your sugar will likely require a compiler change. | |
| Oct 30, 2013 at 20:39 | comment | added | AArteDoCodigo.com.br - Maniero | @RobertHarvey IMHO your answer is not wrong either, just it was not fit in this question. For me it's about language design. I agree with you that C# or even Java team shouldn't waste resources in that feature. I see the usefulness of this feature and I see the cost for the language and for the implementation. | |
| Oct 30, 2013 at 20:24 | comment | added | Robert Harvey | @bigown: Thanks for the vote of confidence. I deleted my answer anyway, which apparently wasn't helping anyone. I wasn't aware, when I answered the question, that this was merely a hypothetical exercise. I did learn a few things, however. | |
| Oct 30, 2013 at 20:10 | comment | added | AArteDoCodigo.com.br - Maniero | @mike20 but if you need to be aware that a type is a resource and you are forced to write something to tell to compiler to do a proper work you're explicit. I disagree with Robert in almost everything he says in this question but he is right saying this answer just get rid of braces and a nested scope and when he's saying the using is not a sugar. | |
| Oct 30, 2013 at 20:00 | comment | added | Robert Harvey |
@mike30: Sorry, but you're wrong. using requires compiler support, because it has to recognize that the type it is using implements the IDisposable interface. It is not simply a language macro.
|
|
| Oct 30, 2013 at 19:57 | comment | added | mike30 | @RobertHarvey. No the using-block is not anything more than sugar. It is exactly equivalent to try-finally-dispose. That's not a bad thing, I love sugar. But it is just that. | |
| Oct 30, 2013 at 19:55 | comment | added | mike30 | @RobertHarvey. I am not proposing replacing using-blocks. I propose to add smart pointers in a "seamless" way. I never suggested removing anything. I am suggesting adding a feature, that feature being implicitness in binding to a scope. | |
| Oct 30, 2013 at 19:52 | comment | added | mike30 | @bigown. I went off on a tangent unrelated to the proposed sugar. If the requirement of scope binding is moved to the type it can be enforced by the type system. This way it cannot be used is a regular heap reference. So there is no requirement for the programmer to "remember" to declare a pointer as smart (like there is in C++). If you cannot possible use the object without the pointer being smart, then it is implicit. | |
| Oct 30, 2013 at 19:51 | comment | added | Robert Harvey |
@mike20: using blocks are more than just sugar. You might as well call async sugar; it's not. Both constructs have special compiler support. Both constructs seek to provide meaning beyond what amounts to a simple syntax variation.
|
|
| Oct 30, 2013 at 19:47 | comment | added | AArteDoCodigo.com.br - Maniero | I fail to see implicitness which is the original requirement from OP. "more implicit than" is strange to me, or it is implicit or it is explicit. Disclaimer: I am just interested in language design here, I'm not saying that C# or Java should implement this. | |
| Oct 30, 2013 at 19:43 | comment | added | mike30 | Do you prefer using-blocks over try-finally-dispose()? It too amounts to nothing but a mundane syntax variation. | |
| Oct 30, 2013 at 19:41 | comment | added | Robert Harvey | I certainly don't favor major machinery changes for what apparently amounts to a mundane syntax style variation. If that makes be seem inflexible, then so be it. | |
| Oct 30, 2013 at 19:39 | comment | added | mike30 | @RobertHarvey. You seem to have a bias against anything not currently implemented in C#. We wouldn't have generics, linq, using-blocks, ipmlicit types, etc if we were satisfied with C# 1.0. This syntax does not solve the issue of implicitness, but it is a good sugar to bind to the current scope. | |
| Oct 30, 2013 at 19:39 | comment | added | Avner Shahar-Kashtan | I've got no problem with semi-practical exercises in language design. | |
| Oct 30, 2013 at 19:37 | comment | added | Avner Shahar-Kashtan | @Robert shrug. I'm not going to open a feature request on Connect for it. I agree that the problem presented by the OP isn't that big. But if I were to try and address it, I'd probably go this route. Programmers.SE doesn't require my solutions to be entirely feasible, do they? :) | |
| Oct 30, 2013 at 19:33 | comment | added | Avner Shahar-Kashtan |
@RobertHarvey Exactly. It sacrifices some flexibity for cleaner, less nested code. If we take @delnan's suggestion and reuse the using keyword, we can keep the existing behavior and use this as well, for the cases where we don't need the specific scope. Have brace-less using default to the current scope.
|
|
| Oct 30, 2013 at 19:31 | comment | added | Robert Harvey | @mike30: Meh. All this syntax does is remove the braces and, by extension, the scoping control they provide. | |
| Oct 30, 2013 at 19:30 | comment | added | Avner Shahar-Kashtan | @mike30 but moving it to the type definition leads you exactly to the problems others listed - what happens if you pass the pointer to a different method or return it from the function? This way the scoping is declared in the scope, not elsewhere. A type might be Disposable, but it's not up to it to call Dispose. | |
| Oct 30, 2013 at 19:27 | comment | added | mike30 | +1. That is some sweet syntax! In some ways even a smart pointer is explicit if you consider the act of declaring the pointer as "smart" to be an "explicit" action. My thought is to move the smartness to the type of the class so it is enforced by the type system. This would catch any non-smart use of the object at compile time and could be considered more "implicit". | |
| Oct 30, 2013 at 19:26 | comment | added | user7043 |
I think using would be a better choice than local, as it's less confusing ("local variable" already means something different which is completely independent from the proposed extension, and using invokes associations with the thing it desugars to). I think there aren't any other issues (it doesn't dispose as promptly but that's the point and inherent to the style of RAII discussed here).
|
|
| Oct 30, 2013 at 19:21 | history | answered | Avner Shahar-Kashtan | CC BY-SA 3.0 |