Sad part is, is that ad hoc unions probably won’t make it into v1. That is probably one of the only feature why I like typescript. Because I can write result types in a good way without creating thousands of sub types. It’s even more important when using Promises and not having checked exceptions.
it's for type purists, because sometimes you want the first element of the list but if you do that you will get T? which is stupid if you know that the list always holds an element, because now you need to have an unnecessary assertion to "fix" the type.
The NonEmptyList in Cats is a product (struct/tuple) type, though; I assume the Haskell version is the same. The type shown in the blog post is a sum (union) type which can contain an empty enumerable, which contradicts the name OneOrMore. The use described for the type in the post (basically a convenience conversion funnel) is different and makes sense in its own right (though it feels like kind of a weak use case). I'm not sure what a good name would've been illustratively that would've been both accurate and not distracting, though.
Well you are right of course, I just wanted to explain what they wanted to show. Of course the type would be wrong if the second entry in itself is an empty list. I just wanted to explain the reasoning what they tried to accomplish
They could’ve done the Either type which would’ve been more correct or maybe EitherT (if the latter is even possible)
I don't think they were trying to accomplish the same thing as the Scala/Haskell version; these are just two completely different things that happen to share a name because the blog post gave the example a name that is confusing when read literally. The purpose of the Cats version is “there is always a head element”. The purpose of the union in the blog post is more like “this can be a collection, but many callers will be thinking of it as a single element, so don't put the burden on them to convert it”. I do think it's a weak case for them in a type theory sense (I would tend to position that kind of implicit conversion elsewhere in the language), but I can also see it being motivating to a large class of developers…
… wait, I've made a different mistake here while trying to explain the difference, haven't I? I was describing it as a sum type, but it's not really a sum type, it's really just set-theoretic union, right?
Which also means OneOrMore is unsound in a different way because it doesn't guarantee that T and IEnumerable<T> are disjoint; OneOrMore<object> initialized from [x] will always return [[x]] from AsEnumerable, won't it? If I'm interpreting the switch expression correctly and the first case predominates, since a list is-an object? I don't have a test setup handy; someone with actual C# experience, please tell me whether that's correct or whether the compiler signals an error here or something…
The online way to prove it is false would’ve to let the LLM create a new uuid algorithm that uses different parameters than all the other uuid algorithms. But that is better than the ones before. It basically can’t do that.
Well since it still not uses a custom port for the client connection and not plain h2 streaming what’s the difference to pangolin? I mean it does not like it has that much more benefits? If clients would also connect to 443 h2 than yeah. But in Corporate environments having a port different than 443 always is a pain no matter the protocol.
Wouldn’t it be possible to automate creating these packages ? I know that it is not the thing that the curl creator needs to do. But if he does not do it, I’m not sure who will. Also I’m not even sure who will use curl via nuget?!
I also think that nuget should be namespaced…
Also as long as you don’t use it to curl random things the security impact is not that high and I doubt that there a tons of uses for that.. you probably won’t attack yourself?
Swift and fil-c are only pseudo safe. Once you deal with the actual world and need to pass around data from memory things are always unsafe since there is no safe way of sharing memory. At least not in our current operating systems. Swift and fil-c can at least guard to some extent the api.
Your take is also a bad one. No what asml builds is not American technology. Why asml succeeded is because they got tons of company’s and people to help them advance the technology of the chip industry. Yes it wouldn’t be possible without the Americans. But it would also not be possible without the Europeans, the Koreans, etc… what asml did was basically ask the technology leaders in each field to build their best product so that they can take their parts and assembly this awesome piece of technology.
reply