Fsharp: Discussion: Do we *really* need a warning when creating Disposables?

[isaacabraham]

The only time I ever use the new keyword is on Disposables, and even then only to silence the compiler warnings. I'm not sure what purpose the warning serves either, because you can still forget to bind the disposable with the use keyword instead of with let. What's more annoying is that it prevents you from effective pipelining: -

use stream = "myfile.txt" |> File.OpenRead |> StreamReader

This code leads to a warning - why? And, could this be removed from the next F# release (or perhaps replaced with a warning if you bind a Disposable with let instead of use)?

[forki]

yeah same here. I have no idea why we need the new or what the difference is. This is what I always feel when I see the warning:

[isaacabraham]

@forki do you have some huge library of animated gifs just waiting to unleash at the right moment?

[ReedCopsey]

The only time I ever use the new keyword is on Disposables, and even then only to silence the compiler warnings. I'm not sure what purpose the warning serves either, because you can still forget to bind the disposable with the use keyword instead of with let.

That's exactly the point - it's incredibly helpful _if_ you get into the habit of never using new except when you're dealing with IDisposable.

I would argue that it'd be more valuable to add a warning when new is used with types that aren't IDisposable...

What's more annoying is that it prevents you from effective pipelining: -

Unfortunately, I agree _in this case_ - but that's only because StreamReader will (by default) close its underlying stream. Many APIs don't do that, so you really should bind the disposable separately.

[isaacabraham]

@ReedCopsey but in my example, that streamreader is bound to the stream value - so you're still binding it to something and can dispose of it etc. etc.

[rojepp]

I would vote to remove the new keyword. There is no need for C# levels of backwards compatibility here. :)
In lieu of that, I'd go with Reeds idea of warning when new is used on non-disposables.

[ReedCopsey]

@rojepp The new keyword is nice, though - it's the only way (currently) to warn you when you don't realize something's IDisposable. I'd be fine with another approach, but it's one of those great safety features F# adds over certain other languages.... Do you have an idea of another approach to warn people if they create an IDisposable? Especially one that works for library authors that return IDisposable from functions?

[ReedCopsey]

@isaacabraham Yes, but that's only because StreamReader specifically disposes the underlying stream - that's not always the case with APIs (or even StreamReader, depending on the constructor used). It's very specific to _that class_, not a general purpose thing.

[sergey-tihon]

warning if you bind a Disposable with let instead of use

I think that we need this one in any case

[ReedCopsey]

warning if you bind a Disposable with let instead of use

I think that we need this one in any case

@sergey-tihon If you're making libraries, this is really common, and necessary. A warning here would be obnoxious and inappropriate. You need to have a way to create (and use) IDisposable types, and return them from APIs.

I could see a warning existing, but I think it'd only make since for types where all of these are true:

• Are IDisposable
• Bound via let
• Not passed into function or constructor
• Not returned as expression result

Using use is completely inappropriate in that case. The current warnings work (but only if you don't use new everywhere), but making it obvious that it's IDisposable due to the new in the construction.

[rojepp]

The new keyword is nice, though - it's the only way (currently) to warn you when you don't realize something's IDisposable. I'd be fine with another approach, but it's one of those great safety features F# adds over certain other languages.... Do you have an idea of another approach to warn people if they create an IDisposable? Especially one that works for library authors that return IDisposable from functions?

There is no safety as long as you can 'new' anything. I use it in the same way as you, but I'd rather not. It is mostly annoying. And confusing for newcomers. I'd still rather see the new keyword be gone. Editors could help with this: https://twitter.com/kot_2010/status/753273628469452805

I agree it is very inappropriate to have a warning when use is not used.

[ReedCopsey]

I'd rather have new be a warning for anything using new that's not
idisposable - you're not always reading code in an IDE or editor, and
especially not in one where it's going to have highlighting that's correct.

On Wed, Jul 13, 2016 at 11:53 AM, Robert Jeppesen [email protected]
wrote:

The new keyword is nice, though - it's the only way (currently) to warn
you when you don't realize something's IDisposable. I'd be fine with
another approach, but it's one of those great safety features F# adds over
certain other languages.... Do you have an idea of another approach to warn
people if they create an IDisposable? Especially one that works for library
authors that return IDisposable from functions?

There is no safety as long as you can 'new' anything. I use it in the same
way as you, but I'd rather not. It is mostly annoying. And confusing for
newcomers. I'd still rather see the new keyword be gone. Editors could
help with this: https://twitter.com/kot_2010/status/753273628469452805

I agree it is very inappropriate to have a warning when use is not used.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/issues/1346#issuecomment-232451709,
or mute the thread
https://github.com/notifications/unsubscribe/AFCUml54PEIo5Vx0n-2DIgFHT6HrpVAJks5qVTQbgaJpZM4JLXUh
.

[smoothdeveloper]

On a side topic, why can't we use use like in C# on existing symbols?

I can't do

let foo() = 
  let bar = new System.IO.MemoryStream()
  use bar
  ()

the keyword is only valid for assignments so I have to do this:

let foo() = 
  let bar = new System.IO.MemoryStream()
  use _ = bar
  ()

[ghost]

@smoothdeveloper is this like:

let foo() = 
  let bar = new System.IO.MemoryStream()
  using bar (fun _ -> ())

[smoothdeveloper]

@xenocons probably, I didn't know about using function, but I think F# deserves a short imperative form to not necessary involve anonymous function.

C# has this

using(bar){
 //
}

we could have that:

do
  use bar
  //

[dsyme]

Point of order: we don't use issues in this repro for language design discussions. Please post on http://fslang.uservoice.com, summarizing the points of view here and linking back here. I know that forum is not perfect for discussions, but it does let people vote, which is useful information too.

[isaacabraham]

Closing, let's create a UV issue on it.

[smoothdeveloper]

@dsyme uservoice has few pain points:

• can't post an idea if you don't have a vote (I don't know the total vote given to an account, but given the number of ideas, maybe we could increase it a bit?)
• formatting in discussions and main posts aren't up to the task (and can't edit)
• it is easy to loose your comment (when you are not logged, you get redirected and input is lost)

I think maybe another process is possible where we'd use UserVoice once an issue on github (but not on this repository) warrants it, UserVoice can still receive ideas, but sometimes people like to discuss on github a bit before (contributing and reading the discussion is so much better); do you think we should use the FSharpLangDesign repository for this instead?

[dsyme]

@smoothdeveloper I don't have a good solution for these things at the moment.

From my perspective I'm happy enough with UserVoice as a long term repository of ideas, votes and discussion - it gives me most the information I need. But I can see it's sub-optimal for those wanting to actively discuss language suggestions at an early stage and have those discussions be recorded in a visible, long-term way. But life isn't perfect, and UserVoice is what we have.

So I don't really have a solution for early-stage discussions that improves things - it's not this repository, and it's not FSharpLangDesign please (that's for RFCs and more "finalized" notes). Perhaps Slack discussions crystallized into well-summarized UserVoice issues would be best for now.

[smoothdeveloper]

@dsyme maybe one of fsprojects org member could make a clone of FSharpLangDesign (with a name like FSharpLanguageDiscussions) and we could move there?

If guys want to discuss on fsharp org slack to find a good solution that would be great.

I understand that github issues in those work repository creates disturbance (with notifications & all).

[cartermp]

Here's my take on this particular thread:

I've never really been much of a fan of UserVoice. I can't quite put a finger on it, but it never seems to be like a place where conversations or detailed design requests are made. Most requests are pretty small in nature, and don't really give a detailed scenario description of something which is sub-optimal today, and then an example of how their proposed feature can make that scenario a joy. The discussion element is also very limited, and discussions are where ideas can be properly teased apart. However, it's got a repository of ideas, it's been out there for quite a while, and UserVoice is something that many, many users of Microsoft products know they can engage with people who work on the things they care about (even if in this case, F# is more than just a "Microsoft product" - but the users are generally people who use Microsoft stuff in their development stack).

I'm also not the biggest fan of GitHub for these sorts of things. Issues are pretty poor at design discussions if there's more than two people involved. The comments appear linear, but the conversation could be going off into multiple threads and looping things back around. Unless you're actively engaged from an early stage, it's difficult to understand what's being discussed and provide a useful contribution. I've experienced that feeling of "wow, I don't even know where to begin" in some of the Roslyn discussion threads.

Slack could also be a challenge. The conversation is linear, and detailed discussions tend to be really hard to have because it's so easy to pop in and give a quick opinion about something. Every time we've tried this with internal Microsoft slacks it gets really challenging and most people give up on it because of chat bubble overload.

Lastly, there are demographics to consider. Where would the majority of F# users go to look for these sorts of things? By nature of inertia, I would think UserVoice. While GitHub has some amazing and deep engagement, many F# users don't know about things going on here. For example, I've spoken with multiple people who use F# and weren't aware of the fact that we've added numerous language features. This doesn't mean they're at fault for not knowing, it just means they weren't watching GitHub. I can't imagine the F# slack being any better in that regard.

In summary, I think the optimal solution would _eventually_ be GitHub if it offered threaded conversations. I think UserVoice probably has the most number of people looking at it, but GitHub is growing and with Microsoft taking OSS seriously it could end up being the place with the most activity and engagement from the community.

But for now, I don't see anything else as a _better_ alternative to UserVoice.

[isaacabraham]

@cartermp Hmmm. Maybe we should whip up some web app for GitHub discussions with all these features ;)

[isaacabraham]

FWIW I've created a UV issue here https://fslang.uservoice.com/forums/245727-f-language/suggestions/15257796-remove-warning-for-new-keyword-on-idisposable