The New JS Features Coming Soon (I'm so hyped)
Вставка
- Опубліковано 21 кві 2024
- Man there's a ton of awesome stuff coming to JS soon. Hopefully. All these proposals are advancing fast. Some can be used today. I'm so hyped. I hope you are too.
SOURCES
- x.com/robpalmer2/status/17565...
- github.com/tc39/proposal-prom...
- github.com/tc39/proposal-shad...
- (Lots more you can find from the Rob Palmer tweet or google - sorry I forgot to save the rest!)
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏 - Наука та технологія
The irony of bagging on firefox immediately after praising MDN.
Yeah, like no one ever has done that with Internet Explorer and Microsoft Developer Network.
0.1+0.2!=0.3 is a byproduct of the actual floating point arithmetic spec, not the implementation, it’s not a javascript issue
Theo's lack of knowledge here was... surprising. Not saying base 10 numbers wouldn't be useful to have in JS... but it makes perfect sense that it's not the default.
@@DavidMulderOne This guy doesn't spend more than an hour on these reaction video's. Lazy content.
I wish it was a more well known fact about the nature of floating point representation. I've seen floats used in situations where the dev was clearly just using it for a lazy convenience, but totally ignorant of the loss of precision they'd just created. Especially bad, because many times those numbers represented financial values.
Yes - I though this was well known. I imagine the advantage of using binary encoded floating point is that it can use the native CPU support for floating point arithmetic if present.
I'm sure he knows it follow the ISO-standard, it's just more fun to complain about javascript.
I'm fine with Firefox slowing down the evolution of JS if the alternative is total domination of web APIs by Google.
totally, google, an US company owning the web is an incredible threat
Especially considering that Firefox does often is not slow to implement, but they have good reasons to not have some web APIs or are not agreeing with the implementation
14:30 - Of course Edge has most features Chrome has - it's still Chrome. Come one, Firefox is not that old, I'm sure they'll manage to implement it shortly. I'm sure Safari has more outdated features & not implemented features
Yeah, what are these awful takes. Isn't this common knowledge at this point?
Theos ingorance surrounding browser monopolies is confounding
He still fanboys apple despite their constant anti-consumer attitude.
Chromium has a near-monopoly because it is better than the other browsers, they're not doing anything wrong.
Nerds will complain on the internet but most of you will never even _attempt_ becoming a Firefox contributor, your loss!
@@pokefreak2112 Chrome has a monopoly because Google controls Google Search and Android and showed Chrome down our throats for the last 10 years. It's not miles ahead of other browsers in anything really. Not saying it's not good, just saying it's not that better than others. Although there was initial period when Chrome appeared when it really was a breath of fresh air in browser wars.
@@pokefreak2112 🤣 You're trolling
@@tiedye001 Not really though. Between Chrome 124, Safari 17.4, and Firefox 125 on Can I Use, Chrome has almost all of the features supported or at least partially supported, where as Firefox and Safari have a lot more Red than Chrome
The whole 'even Edge' has it is a bit tiring considering it's using effing chromium in the first place.
Not sure if it was meant to be funny? The fact that engineers from both Google and MS are going full time on V8 while Gecko is being starved to death with barely minimum resources. Saying Firefox is holding back web is like saying the resistance is holding back the world domination. smh
comparing multibillion orgs with non profit mozilla and saying that it lags behind sure is strange move
Yeah it's a silly comment from him that doesn't seem to understand that Chrome and Edge are basically skins on top of Chromium. There are also instances where Firefox had support for something years before Chromium. For example subgrid is one of them and also animating some flexbox features.
To be honest, In the last few years I had way more issues supporting Safari than I've had Firefox on anything I've worked on. Safari and especially Safari on iOS always have the weirdest issues.
It's actually admirable that Mozilla is managing to keep up with Chromium at all considering the lack of resources.
@@rand0mtv660 I think Theo is laughing his ass off seeing how a handful of people are triggered for no reason lol.
He prolly understands the gravity of his statement, but he just likes to have fun with Firefox people haha.
@@ky3ow So, let's talk about Safari
14:45 "even Edge has it". Bro, they implemented it only like two months ago. It's not like you can start using the feature and ship it to users since most users probably still haven't updated to latest browser version. Of course you can just use it anyway and bundler will transpile it to some polyfilled code so that browsers you support will be able to run it. In that case Firefox support doesn't really matter.
But same can be said other way around for something like CSS Subgrid. We would have been able to use it for years now if Chromium implementation didn't lag behind Firefox for almost 4 years. Yes that's right, 4 years, not 4 months. Unfortunately something like subgrid cannot even be polyfilled.
Firefox holding back a feature, thats under a year old in other browser doesn't seem to bad to me.
a feature that is polyfilled so holding back slight performance gain not the feature as whole at all XD
date time functions are what im crazy hyped for
The 0.1 + 0.2 thing is floats acting exactly as defined and not at all JS's fault. 0.1 + 0.2 != 0.3 in Python either, for instance.
What JS lacks, however, is a builtin Decimal type and/or Rational type. Imagine if JS actually had Scheme-style exact numbers, rationals, and even complex numbers. It'd be pretty nice.
If we go into complex numbers territory, then we should also add GA rotors.
It has BigInt, though 🙂
@@EdwinMartin BigInt != BigDecimal
@@MelroyvandenBerg Klopt
I had to implement my own Decimal type for counting money which is perfectly discrete to the cent
Wow… “Once again Firefox is holding back the internet” is a really bad take. Firstly, they have a much smaller team than any of the other browsers. And secondly, the “once again” part is totally unfair. Safari is just as bad if not worse, and chrome isn’t perfect either. Specifically in this case, the behaviour can be and is polyfilled so they’re not holding back shit.
What does polyfilled mean?
@@Darkstar159 A third party library/your own custom implementation that fills the missing feature.
As I've mentioned in one other comment, I personally had way more issues supporting Safari (especially on iOS) rather than Firefox. But Safari team is definitely stepping things up, I think in the last 1-2 years they invested significantly more effort into Safari and implementing the spec.
Only downside is that Safari is still tied to OS updates and not independent so people that don't want to update the OS also don't get latest Safari.
Agreed, safari can be awful.
Safari has soo much bugs we have to mitigate on my work...
Babe, wake up, LINQ for JS just dropped
Looks more like Java's stream api
it's funny to see js becoming c#
@@mrkostya008 they’re all just specialized monads in the end, so same thing different name
@@mrkostya008 It's LINQ. Plain as day.
If he this excited to see literally LINQ from C#... it's 2024. LINQ was there in 2007, and it borrowed from Haskell.
But never mind. If this guy actually saw what LINQ to SQL does. I don't think he'll understand it at first. And then he'll have a "holy shit!" moment six months later.
We won't get into building LINQ expression trees
Welcome to 2007, dear JavaScript! 🙂
Best Regards,
LINQ
JS turning into C# 😀
Tbh I’m just waiting on full type / ts support
More things directly in ECMAScript is so good. Simplifies the ecosystem
i'm sure you've just overlooked that i'm eminently reachable, if you want to talk about tc39 proposals :-p
Majority of games engines don't need precise floating point math and would be negatively impacted by it because fadd is an instruction on the cpu assuming zero overhead from V8. Only games that come to mind could use something like that is KSP and Minecraft but there are cheaper workarounds neither of which are in JS. This would be more useful for currency but who even uses floats for currency. Also simulations but noone is writing simulations in JS either.
All numbers in JS are floats.
9:50 0.3 isn’t even a valid floating point number. The closest is like 0.300000011920928955078125
js slowly morphing into c#^^
One of the best things about match is that it will hopefully be an expression. which if statements and switch statements are not.
I like Firefox man. How the flipped pancakes did Set get in js without those set functions at the same time. Also where are the iterator functions `pairwise`, `chunks` or `windows` :(
You are a senior developer (allegedly), how do you not know that the floating point arithmetic it’s not a javascript issue
Those were all super cool. I love the iterators, but I'm most excited for Temporal.
Me too. In my job we slice and dice and compare and add time, dates and durations.
We have a lot of legacy horror that is going to be dumped.
I started using the temporal polyfill for now and it's great. Only downside is converting back to regular dates when interfacing with other libraries
Answering your question at the end of the video - I would like to see focus on the parts which are not already seen in other common languages. Stuff like iterators, set functions, lazy generators are all common things. I would like to see more about things like those shadow realms
this iterator stuff is all the stuff i miss in ts when coming from c#. although `skip` seems to be called `drop` for some reason. now just to have a built-in `iterator.range` method
2:50 "Defer" is one of my favorite features of Go so I'd like to see "using" implemented because such block scoped execution of code is really useful. Of course in many languages blocks are defined merely with braces so the closing block isn't necessarily defined by a function or a method but it usually is.
Ah, filter/map/reduce for iterators. JavaScript finally gets Java's Stream methods, with all the performance-enhancing benefits it brings.
You mean Java *finally* got it in 2014 after C# introduced LINQ in 2007?
It was pretty trivial to create map function for iterators already, these extensions just make it a little bit easier and more natural. eg. a map iterator function -> function *map(i, fn) { for (const a of i) yield fn(a); }
@@proosee oh, you mean the stuff that Haskell has had out the box since at least Haskell98 and most likely even Haskell 1.0 from 1990?
(which is before Java and C# existed)
@@asdfghyter yes, but well, don't judge me if I don't count Haskell as mainstream, widely used, well supported language. Maybe when Haskell earn some decent package manager after existing for over 30 years then I will reconsider.
@@proosee sure, it isn't mainstream and it certainly wasn't back then, but that's kind of the point. mainstream langagues are very slow to adopt good features from more academic languages like Haskell. And as I said, it existed even before someone had considered making either of the languages, so they don't have the excuse of it being something new
insta-watched, just to see if pattern matching and pattern matching overloads have been mentioned 😢
Nice! 🎉 It’s about time for temporal.
Would definitely like a video on the history of dates in JS. When I first started writing JS the lack of something built in like Python’s DateTime was something I found kind of baffling.
I've been away from JS for a year or two, in C-land and Python 3D modeling. Now, converting my Hugo static sites from JS to TS (which is so easy). Good to see so much new goodness coming to JS.
One thing with the floating sum logic is that it will _add_ precision, not remove it. So if you have something like `sum([FLOAT_MAX , 1.0, -FLOAT_MAX, 2.0])` youd expect sum to give (not quite) 3.0. But a reduce (in array order) will drop precision a bunch and give you something like 2.0 instead
0.1 + 0.2 !== 0.3 is not a precision issue in the summation, it is an untrue statement if 0.1, 0.2 and 0.3 are meant to be the closest double precision base 2 approximations of the respective decimal numbers. Also, Math.sumPrecise(...) will never yield a different result than simple addition for just two numbers, since the addition of two numbers is already required to produce the correctly rounded result. A better demonstration would be Math.sumPrecise([1, 1e-20, -1]) === 1e-20 instead of (1+1e-20)-1 === 0.
0.1 in the source code is defined as the closest double precision approximation, which is 1.10011... * 2^-4 (repeating 0011 patterns in the ... for a total of 53 digits).
Closest double precision number to 0.2 is the same, except the exponent is -3 instead of -4.
Adding those two exactly yields 1.0011...00111*2^-2, the last 1 is one digit too many for double precision and since default rounding is to even, we round up to get 1.0011...0100*2^-2, roughly 0.3000000000000000444 (~4.44e-17 away from 0.3), which is the correct closest double approximation of the exact sum of the closest double approximations of 0.1 and 0.2 but it is not the closest double approximation of 0.3, which is roughly 0.2999999999999999889 (~1.11e-17 away from 0.3).
There is no way to make tests like base2ApproximationOf(0.1) + base2ApproximationOf(0.2) === base2ApproximationOf(0.3) reliably true with binary floating point semantics, regardless of the number of digits because it is fundamentally untrue. And changing the implicit meaning of 0.1 away from base 2 float to some decimal type would be a severe performance hit for all numerics in JS and definitely break things that use binary floating-point in an intentional way .
Thank you, Theo!
I like seeing more and more C#/F# showing up in JS.
The Iterators methods are amazing! I have a use case in our app which I think would really benefit from this.
you can also use switch true statements instead of match. its a very cool trick
3:33 Technically C++ is here too, but "cleanup" is integrated into object lifetime itself by destructors
Temporal has been stage 3 for so long I can't even remember anymore
I still reach for `reduce` for filter / mapping to skip a loop. Did everyone move over to `flatMap` instead?
No one did. People moved back to loops because they are simple to write, simple to edit, easy to get performance, often easier to debug, and everyone knows what a for-loop is regardless of background and skill.
You can communicate somewhat with an iFrame using the postMessage method. It's a pain but we've done stuff like drag and drop content between iFrames and the parent and send data back and forth.
I totally ♥the consistency of how `JS is being JS` even after some fancy math optimization propasals :)
Linq coming to javascript?
I think they should make the interaction with shadow realm use promises.
If possible, they could use one free thread to run any potentially lengthy code and post the result back to the main thread.
9:50 not earlier than we will store floats differently in memory
What's the advantage of ShadowRealm over Web Workers? Web Workers (when properly configured) allow for fully sandboxed code execution, although I acknowledge that ShadowRealm makes it easier to intentionally write it as single threaded code, but it doesn't sound like it would allow for new applications, just makes it easier to write certain things.
It might not be a perfect take, but I have several guesses:
1) AFAIK, workers require an event listener or a broadcast channel, this might make it harder to get a type safe implementation with typescript (without a library to abstract it or some type magic)
2) I'm not certain about the efficiency of instantiating web workers. A quick google search got me 40ms, it's probably inaccurate, but it sounds about right. What we want from web workers isn't fast instantiation. In the case of the shadowrealm, you'd expect a realm to be fast to initialize and throw away.
3) Web workers don't exactly have the same environment as regular js land. You might want your "unknown" isolated code in the shadowrealm to be able to access every single JS API while isolated. Workers are known to be workers at dev time, we don't expect realm code to know it's in a realm and still run just fine.
4) Going back to efficiency, because the shadowrealm does not serialize or deserialize, it's also that much faster. It still uses the heap instead of reserving its own memory. In that sense, it's weaker isolation, but it fulfills its purpose.
The api is very different, workers need explicit communication back to the main thread but the realm stuff is just calling a function so theres no 'contract' the code in isolated realm needs to uphold
@@TurtleKwitty Yeah, it's single threaded and the API is quite different. I was mostly responding to his comment that it would allow for new stuff. As far as I can tell you could polyfill ShadowRealm's API fully with web workers (it just would be multi threaded)
I can't wait for realms. Just a small correction. You can isolate and communicate with an but it's very complicated, requires understanding CSP and the worst part is its async comms only. Realms would be like a safe evaluate although you still have to be very careful not to shoot yourself in the foot. Am currently trying to create a safe plugin system for a project and I'm using s + the realms shim. The is for extra security against flaws in the shim + dom access + control over network access using csp rules. Lots of hacks were involved to get things working.
Did you hear about/try Effect? They plan to add some of these features themselves... But in general, wanna hear you thoughts on it.
Dude, Firefox also have features implemented a long time ago which you need to wait for other browsers to support it!
What browser do you use, Theo?
I'd like you to do a comparison of JS Iterators and Java Streams and Gatherers (JEP-461). As a Java dev it's sometime hard to get my head around JS.
I remember dealing with dates difficulties in the 80s and thinking "how is this not already done?". Strings too. And CSVs.
I'm not a JS dev, but for some reason, I thought it already had this stuff. Mind blown.
8:15 “0.5? I cant recall”…I see what you did there…
Only we understand.
21:20 I mean, it's really not an implementation issue, it's just how iterators as objects work.
In our case, it seems like the source iterator mutates when using take. It wouldn't be take if it allowed going beyond the set limit.
On the other hand, if the iterator didn't mutate, a new take would start again from 0.
So no matter what "version" of take you do, none could support that behavior.
I do agree it would be nice to have a method that returns a number of values *and* mutates, but the implementation would need to be a single call returning an array, rather than a method returning a new iterator. In the end, it's a bit too specific to be part of the base language.
I've read your comment a few times and I'm still not sure what you mean exactly. Regarding the closing of the underlying iterator when take() is exhausted, it's not an obligatory side effect of the iterator protocol but a deliberate choice by the authors of the proposal to avoid memory leaks. Iterators may have resources that must be freed, but they can't until the iterator completes. Let's say you've got an iterator that reads a file line by line. First, it opens the file, then it yields a new line after each next() call until it finishes, then it closes the file. If the file is 20 lines long but you only take 10, the file would never be closed if take() didn't call return() on the original iterator.
@@piaIy If take built an iterator that passed the done flag at index i, yet could continue after said flag, it wouldn't be an iterator. It'd be some sort of zombie hybrid type gluing two iterators together. The best way to insist on having that implementation would be to have an additional exhausted flag or an exhausted method.
The done flag does not just indicate the end of the iterator, but also the exhaustion of said iterator. An exhausted iterator should be thrown away, and going against it would mean that every library developer would have to deal with the possibility of a second iterator hiding behind the first, either ignore it (no code change, but an unsupported feature) or handle it (code changes everywhere).
@@Exilum these methods create a new proxy iterator that delegates the calls to the inner iterator, but it also has its own state. If you have an infinite iterator named _x_ and you define _y = x.take(1)_, it won't mutate x right away, you can still call x.next() as many times as you want to get the next value. Only when you call y.next() for the 1st time will it mutate x and jump to the next value, and when you call it again, both will be done, including x. But this last behavior is an implementation detail for extra safety, you could still write your own take(innerIterator, limit) generator that would yield the value of innerIterator.next() in a loop up to the limit, then return without closing the inner iterator. Your take generator wouldn't yield any new value, it would be exhausted without affecting the other, but then you would be responsible for cleanup (you could call innerIterator.return() to accomplish this). It's even possible to get around the cleanup behavior of the built-in take(); you can wrap the yield statement in a try-finally block and change the control flow, like using continue in a loop, but this has its own drawbacks, like making it trickier to intentionally close the iterator with return().
LOL welcome to Groovy 15 years ago. But honestly, many of these features are kind of great. I use to just hate Javascript, but now I'm a Nextjs/Typescript dev and I am enjoying the language.
chaining on iterables will consume completely the previous iterable because that's the only thing that can be relied on, otherwise side effects would be surprising. I wouldn't be surprised if after n.take(5) the state in n is completed already, even without iterating the n.take() result with toArray
Iterator helpers are a tease for algebraic data types, which would be immense for js
The iterator proposal is years old. Take has been around for a while, same for foreach, map, etc
I'm more than a little curious if JavaScript can be used to implement a custom floating point interpretation. I've partially implemented the operations in C, + - * /, and I can't imagine that it would even be possible in JavaScript without the ability to do a reinterpreting cast on the bit patterns.
The thing I keep thinking about with all of these additions they keep coming up with is that we're going backwards in terms of functionality. We should be aiming to speed things up and all of these functional design patterns just slow us down and make the code more difficult to read. It feels like every advancement in computing power we've gotten has come with a devolvement in software which erases all of the advancement.
Old school game engine I wrote had a custom float adder but everything was custom back then when the first Voodoo cards hit.
can't wait for libraries, like typescript, to have things that bud head
This ShadowRealm proposal is the thing that Figma want(ed) to run 3rd party plugins within Figma or am I tripping?
pattern matching is only good if you can have it in function signatures like in Elixir. If not, it is just another way to do if (like the switch/case too).
Awesome analysis! I am not a big fan of JS on the server possibly due to my background being data centric, but on client side these are cool toys. Date handling is a clear win. Any effort to move Typescript into JS is mostly a good idea. Unfortunately, they said type safety and true OOP cannot be possibly added to JS. Not sure why.
I use reduce for function composition all the time?
It's funny, because in some other languages, 'using' is often called 'with', the idea being that once the 'with' block has finished, it auto-cleans up. About time JS gets something like that.
Really funny to see features give been using in so many other langs. These new updates will be good though for those langs - effectively compile to the native op.
Also, floating point additions will never be resolve the problem of 0.1 + 0.2 because of IEEE754. You have to use high/infinite precision.
Cool, a full streaming API on generators.
I don’t use reduce often but I recently found myself using it to traverse a tree like structure. While writing this I realize the final code I ended up with doesn’t need the reduce. Im going to rewrite
20:20 now you just need the "naturals" function built-in
- So all I had to do was to imitate what Python has been doing so far!
- Congratulations Shinj... Javascript you figured it out!
👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏
C# has had those iterator functions since 2007, and its implementation of them is a million times better. JS is so far behind it boggles the mind. Even after this proposal you still can’t run .map/.filter on document.querySelectorAll. You still have to jump through a hoop (.values()) to get .map/.filter on arrays to be lazy. Etc.etc.etc.
For personal reasons the set stuff. For current business reasons I would love shadow realm!
I use Set difference & intersection in Python on a daily basis -- this is dope
I'm used to using being something to include a scope into your scope.
For example:
Foo :: struct { a : int; }
main :: () {
foo : Foo;
foo.a = 1;
using foo;
a += 1;
}
So seeing it more like an abstraction of defer is weird.
I actually wrote my own decimal implementation so that I could have accurate sums. Then I decided to find a package for it instead.
I was building a spreadsheet :)
19:46 I’m half way through. I hope there’s a proposal for extension methods!
It's great that the new Set composition methods also accept Set-like operands, e.g: `new Set([1, 2, 3]).union(new Map([[3,"3"],[4,"4"]]))` => `Set{1,2,3,4}`
I use reduce a lot for several operations in a single array iteration
Shadowrealm reminds me of Tampermonkey. Is that the same concept ?
Gecko may be a bit slower to implement things that Google invented, but it's Chromium that has terrible user experience, missing the most basic features
sure, Quantum isn't as good as Firefox was, but it's the pressure to compete in benchmarks and implement all the craziest ideas that forced them to give up most of the power
and yet Quantum still offers much more than Chromium, The Unusable
What is Quantum here? The Firefox redesign you mean? And why do you think Chromium has terrible UX? I think Chrome browsers in general have bad devtool experience (atleast the looking part) but from a user perspective, i think its fine.
@@ark_knight Quantum is the browser that replaced Firefox, different goals and priorities, but the legacy components can still be used to bring back most of the power Firefox had
Chromium has a terrible extensions API (true, WebExtensions are based on that and most of the issues persist, but at least uBO works as expected), you can't configure your toolbar as needed, you can't remove close tab buttons that only bring despair when the browser isn't able to fully restore the state of just closed tab, no way to get mouse gestures to actually work unless implemented natively (WebExtensions force the use of ContentScripts, and these only work within the viewport, need to be injected into AL frames, and can't be injected into some classes of pages leading to inconsistent flow), the long lasting text rendering issue finally got partially patched in upstream, I think over a year after MS prepared the patch, but image scaling issue persists
and don't get me started on mobile...
Temporal is the goat. I remember going to a temporal system in java and it made so much stuff so much easier
Another usecase for ShadowRealm is to execute the proxy autoconfiguration file (PAC) when doing an http request without giving the network admins the ability to run arbitrary code in your machine.
I didn't have time to dive into Temporal yet, because I've not allowed time when creating my schedule and that isn't mutable
Wow, JS is starting to look like C#.
Lot of C# influences.
I use reduce quite a bit, but I don't use JS frameworks, so my JSON returns arrays, and now I need reduce to sum shit up!
JavaScript is turning into C# and I'm all in for it! :D
23:45 What font does he use?
lol @ struggling with iterators but they're super cool i'm so hyped
I've been waiting for Record and Tuple for 5 years. This would help with doing primitive equality on object and array like structures without relying on external isEqual function check.
JS is looking more and more like python but with braces
If you can chain drop() and take() then this will be truly amazing!
Iterators are dope, for me it's the ability of doing .map().filter().map() (or similar) without worrying about the performance
omg i neeeed the Temporal stuff
Looks like js get's to be more like c# 🎉 good stuff. I like and use them both 😊
Is Temporal out yet?
Enforcement of using seems terrible. There have been many times in C# where I have wanted to deliberately not dispose a resource at the end of a statement, and enforcing using would mean needing to spawn a thread that sleeps infinitely just to get around that. Language designers should not encourage harmful patterns just because a small subset of developers make dumb mistakes.
implement IDisposable interface perhaps?
The proposal only adds a mechanism of enforcement, and whether a Disposable requires `using` or not is dependent on the library defining the Disposable. Language designers are not enforcing `using` in general; it is opt-in (for libraries).
> Were such enforcement to be mandatory, these hosts [Node, DOM, Electron etc. who provide disposables] would need to implement and maintain a completely parallel set of APIs purely to support using. As a result, we are proposing this as a purely opt-in mechanism that could be leveraged by new APIs that need stronger enforcement guarantees.
And it's also still stage 1 anyways. If it still doesn't sound like a good idea, now's the time to strike it down.
Disagree, this is how memory leaks happen.
The language should prevent the programmer do be able to do dumb things like never dispose resources, but also provide interfaces when you want more control.
@@kisaragi-hiu I understand that it is an optional and separate from the primary Disposable of the proposal, however the fact that it exists is a problem, as inexperienced or close-minded developers won't see the difference between the APIs or will not be open to changing a forced API to a non-forced API.
@@neociber24 At the moment, it is easier than ever to not dispose resources, and `using` will only make it harder. That doesn't mean you should make it 100% impossible to manage disposables because of a few clueless developers. Having a forced `using` disposable is as dumb as the leniency of ==, and if it gets through there will probably be a feature added in the future that allows you to bypass the forced `using` just like ===.
Let's imagine that you have an API that returns a `binaryStream` that can be read from and written to. In this hypothetical, the stream only accepts bytes on its `write` methods and implements forced disposable.
Now, you have decided that you need to write some strings to the stream, however manually converting to bytes is a little tedious. The solution is to create a `binaryStreamWriter` object that takes ownership of the stream and exposes both byte and string `write` methods.
Now realize that the existence of the `binaryStreamWriter` object is impossible because of forced disposal. Forced disposal does not allow for transferring of ownership because it will always be disposed by the scope it was declared in via the `using` keyword.
Even if you were to fetch the `binaryStream` within the writer, you still would not be able to store it as a property of the writer because it would be disposed by the scope of the writer's factory method. The only true way around it is to use a separate thread that never exits the factory method due to a `while (true)`, and that is arguably way more harmful than forgetting to (or not knowing to) dispose resources.
So I ask again, why would you hurt experienced developers just because of a small subset of clueless developers who do not know how to use a language.
js: yeah, so we invented Sets, data structure known to men since Ancient Greeks, and available in almost every other programming language.