digitalmars.D - OT: (C#) Type Unions for C#
- ryuukk_ (8/8) Aug 02 Some people over here like to take C# as inspiration for new DIPs
- Sergey (3/6) Aug 02 Only if some IT giant will decide to invest 100+ full-time
- ryuukk_ (8/14) Aug 02 Bullshit, R&D already done many decades ago, it's a common
- Kagamin (1/1) Aug 05 C# does it to appeal to webdevs as microsoft bets on Azure.
- Kapendev (4/8) Aug 06 Tagged unions in C# seem quite complex. 🤢
- Quirin Schroll (12/21) Aug 12 It seems Odin has type unions. I actually dislike their approach.
- Richard (Rikki) Andrew Cattermole (5/8) Aug 12 There is also tag based unions where order doesn't matter.
- Quirin Schroll (26/34) Aug 13 What I intended was writing “Non-tag-based type unions where
and go submit a PR Don't become a relic of the past, move forward https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md D should be leading, there is no reason for D to remain a relic
Aug 02
On Friday, 2 August 2024 at 10:29:22 UTC, ryuukk_ wrote:D should be leading, there is no reason for D to remain a relicOnly if some IT giant will decide to invest 100+ full-time professional devs into research and development :)
Aug 02
On Friday, 2 August 2024 at 10:43:56 UTC, Sergey wrote:On Friday, 2 August 2024 at 10:29:22 UTC, ryuukk_ wrote:Bullshit, R&D already done many decades ago, it's a common feature, it's not a novel thing https://odin-lang.org/docs/overview/#unions Fast compilation is the only thing that makes me resist from porting my current game to an other language, and these languages are getting there too.. D should move forward, fastD should be leading, there is no reason for D to remain aOnly if some IT giant will decide to invest 100+ full-time professional devs into research and development :)
Aug 02
Sergey <kornburn yandex.ru> On Friday, 2 August 2024 at 10:54:59 UTC, ryuukk_ wrote:Bullshit, R&D already done many decades ago, it's a common feature, it's not a novel thingMy answer is general, not only about these two things. Research is never stop =) GC, ownership and other things.https://odin-lang.org/docs/overview/#unionsIf the language is big and has a lot of features you need a lot of resources for proper implementation, that all these things work flawlessly together.Fast compilation is the only thing that makes me resist from porting my current game to an other language, and these languages are getting there too..https://github.com/nordlow/compiler-benchmarkD should move forward, fastIf there will be more developers and contributors for sure :)
Aug 02
On Friday, 2 August 2024 at 10:54:59 UTC, ryuukk_ wrote:On Friday, 2 August 2024 at 10:43:56 UTC, Sergey wrote:Odin is far for being a model. Not self hosted, many bugs, poor implementation, poor test suite.On Friday, 2 August 2024 at 10:29:22 UTC, ryuukk_ wrote:Bullshit, R&D already done many decades ago, it's a common feature, it's not a novel thing https://odin-lang.org/docs/overview/#unions Fast compilation is the only thing that makes me resist from porting my current game to an other language, and these languages are getting there too.. D should move forward, fastD should be leading, there is no reason for D to remain a relic of the past, no industry rely on D, yet they rely onOnly if some IT giant will decide to invest 100+ full-time professional devs into research and development :)
Aug 02
On Friday, 2 August 2024 at 19:53:15 UTC, user1234 wrote:On Friday, 2 August 2024 at 10:54:59 UTC, ryuukk_ wrote:It just takes me 1 minute to bring an evidence: - https://github.com/odin-lang/Odin/issues/4001 - https://github.com/odin-lang/Odin/commit/fdfe6b00e0e8558050ebd6e6c7cb33b3d789be4f nothing proves that this cannot break again. I see many things like this in Odin, Zig, Nim, V, etc. In my opinion, and as I consult often many PL bug trackers, there is a serious lack of methodology in all those "alt" languages, especially when they are hosted on GH...just to make some clicks.On Friday, 2 August 2024 at 10:43:56 UTC, Sergey wrote:Odin is far for being a model. Not self hosted, many bugs, poor implementation, poor test suite.On Friday, 2 August 2024 at 10:29:22 UTC, ryuukk_ wrote:Bullshit, R&D already done many decades ago, it's a common feature, it's not a novel thing https://odin-lang.org/docs/overview/#unions Fast compilation is the only thing that makes me resist from porting my current game to an other language, and these languages are getting there too.. D should move forward, fastD should be leading, there is no reason for D to remain a relic of the past, no industry rely on D, yet they rely onOnly if some IT giant will decide to invest 100+ full-time professional devs into research and development :)
Aug 02
On Friday, 2 August 2024 at 20:07:02 UTC, user1234 wrote:On Friday, 2 August 2024 at 19:53:15 UTC, user1234 wrote:Brother, don't be jealous, they are young languages, built by young people, they have a whole life ahead of themOn Friday, 2 August 2024 at 10:54:59 UTC, ryuukk_ wrote:It just takes me 1 minute to bring an evidence: - https://github.com/odin-lang/Odin/issues/4001 - https://github.com/odin-lang/Odin/commit/fdfe6b00e0e8558050ebd6e6c7cb33b3d789be4f nothing proves that this cannot break again. I see many things like this in Odin, Zig, Nim, V, etc. In my opinion, and as I consult often many PL bug trackers, there is a serious lack of methodology in all those "alt" languages, especially when they are hosted on GH...just to make some clicks.On Friday, 2 August 2024 at 10:43:56 UTC, Sergey wrote:Odin is far for being a model. Not self hosted, many bugs, poor implementation, poor test suite.On Friday, 2 August 2024 at 10:29:22 UTC, ryuukk_ wrote:Bullshit, R&D already done many decades ago, it's a common feature, it's not a novel thing https://odin-lang.org/docs/overview/#unions Fast compilation is the only thing that makes me resist from porting my current game to an other language, and these languages are getting there too.. D should move forward, fastD should be leading, there is no reason for D to remain a relic of the past, no industry rely on D, yet they rely onOnly if some IT giant will decide to invest 100+ full-time professional devs into research and development :)
Aug 02
On Saturday, 3 August 2024 at 04:00:51 UTC, ryuukk_ wrote:On Friday, 2 August 2024 at 20:07:02 UTC, user1234 wrote:Sorry for my previous words, they were not argumented. On top of that I would not like contributing to the "language war", so let me explain: I just cant stand his position on bootstraping. You see D had the same problem. You had to be a C++ programmer to contribute. Dont you see not to bootstrap is absurd ? At some point you propose something new instead of the old thing, but you have to master the old thing to contribute to the new thing. Just "comon you guys". If you are afraid of the self hosting process then just admit that fact and dont pretend that "self hosting before a stable language and compiler exists is masturbatory pleasure" (I quote).On Friday, 2 August 2024 at 19:53:15 UTC, user1234 wrote:Brother, don't be jealous, they are young languages, built by young people, they have a whole life ahead of themOn Friday, 2 August 2024 at 10:54:59 UTC, ryuukk_ wrote:It just takes me 1 minute to bring an evidence: - https://github.com/odin-lang/Odin/issues/4001 - https://github.com/odin-lang/Odin/commit/fdfe6b00e0e8558050ebd6e6c7cb33b3d789be4f nothing proves that this cannot break again. I see many things like this in Odin, Zig, Nim, V, etc. In my opinion, and as I consult often many PL bug trackers, there is a serious lack of methodology in all those "alt" languages, especially when they are hosted on GH...just to make some clicks.On Friday, 2 August 2024 at 10:43:56 UTC, Sergey wrote:Odin is far for being a model. Not self hosted, many bugs, poor implementation, poor test suite.On Friday, 2 August 2024 at 10:29:22 UTC, ryuukk_ wrote:Bullshit, R&D already done many decades ago, it's a common feature, it's not a novel thing https://odin-lang.org/docs/overview/#unions Fast compilation is the only thing that makes me resist from porting my current game to an other language, and these languages are getting there too.. D should move forward, fastD should be leading, there is no reason for D to remain a relic of the past, no industry rely on D, yet they rely onOnly if some IT giant will decide to invest 100+ full-time professional devs into research and development :)
Aug 06
On Friday, 2 August 2024 at 19:53:15 UTC, user1234 wrote:On Friday, 2 August 2024 at 10:54:59 UTC, ryuukk_ wrote:see https://odin-lang.org/docs/faq/#is-the-odin-compiler-self-hosted This is one of the most stupid thing I've ever read.On Friday, 2 August 2024 at 10:43:56 UTC, Sergey wrote:Odin is far for being a model. Not self hosted, many bugs, poor implementation, poor test suite.On Friday, 2 August 2024 at 10:29:22 UTC, ryuukk_ wrote:Bullshit, R&D already done many decades ago, it's a common feature, it's not a novel thing https://odin-lang.org/docs/overview/#unions Fast compilation is the only thing that makes me resist from porting my current game to an other language, and these languages are getting there too.. D should move forward, fastD should be leading, there is no reason for D to remain a relic of the past, no industry rely on D, yet they rely onOnly if some IT giant will decide to invest 100+ full-time professional devs into research and development :)
Aug 02
On Friday, 2 August 2024 at 10:29:22 UTC, ryuukk_ wrote:DIPs DIP and go submit a PRMaybe the OdinLang implementation might be a better inspiration: https://odin-lang.org/docs/overview/#unions
Aug 06
On Tuesday, 6 August 2024 at 19:44:12 UTC, Kapendev wrote:On Friday, 2 August 2024 at 10:29:22 UTC, ryuukk_ wrote:It seems Odin has type unions. I actually dislike their approach. IMO, you have two sane approaches: * Plus-like type sums where order doesn’t matter, duplication doesn’t matter and they auto-inline. The empty plus-like sum is `noreturn` and adding `noreturn` to a plus-like doesn’t actually add it, so that `S+(T+noreturn)` is another way to spell `T+S`. * Tag-based type unions where order matters, duplication matters (different tags), they do not auto-inline, and the empty one is at definition site its own type. From a plus-based type sum, you extract values asking for a value of some type. From a tag-based one, you request by tag.DIPs DIP and go submit a PRMaybe the OdinLang implementation might be a better inspiration: https://odin-lang.org/docs/overview/#unions
Aug 12
On 12/08/2024 10:32 PM, Quirin Schroll wrote:Tag-based type unions where order matters, duplication matters (different tags), they do not auto-inline, and the empty one is at definition site its own type.There is also tag based unions where order doesn't matter. I.e. hashed tag name/tag type. This is the one I propose, as it allows changing the sumtype elements without having to perform a match.
Aug 12
On Monday, 12 August 2024 at 10:37:08 UTC, Richard (Rikki) Andrew Cattermole wrote:On 12/08/2024 10:32 PM, Quirin Schroll wrote:What I intended was writing “Non-tag-based type unions where order matters” etc. where you extract by index. For tag-based unions, you’re right, order should not matter, same as order of data members in a `union` type doesn’t matter. The gist is: There are actually four kinds of type sums: Plus-like, list-like, and ad-hoc and user-defined tagged. Examples: - JSON values are reasonable as a plus type: `alias Json = double + string + bool + Json[] + Json[string] + typeof(null)`. - Value exceptions are list-like: `Result = Expected ~ Unexpected1 ~ Unexpected2`. An unexpected type might be identical with `Expected` but semantically different. Even two unexpected results might be same-type but semantically different. If that’s not intended, one can use `Expected ~ (Unexpected1 + Unexpected2)`. - Most high-level user-defined sum types would be tag based. I implemented something like that some time ago in a library. What the library does is provide a mixin template so that users can create their own tag-based sum types. What it didn’t offer, though, was ad-hoc tag based unions, probably because of limiting syntax. I didn’t like seeing `Sum!(int, "x", long, "y")` in error messages because those things get long quickly. For the mixin template, I use an “implementation struct” that provides the types and members.Tag-based type unions where order matters, duplication matters (different tags), they do not auto-inline, and the empty one is at definition site its own type.There is also tag based unions where order doesn't matter. I.e. hashed tag name/tag type. This is the one I propose, as it allows changing the sumtype elements without having to perform a match.
Aug 13