The | character is used in a few different languages as a concise way to specify type unions, like in TypeScript, Scala, PHP 8+, Python 3.10+, and (sort of) Haskell. I was curious to hear what people’s initial thoughts would be on having this as a concise way to create Unions. This would be complete…

[image] mkitti: Sets are intensional consisting of elements which belong to the set, while types are extensional with members that can be constructed to be of certain types [1]. That is the converse of what is written in the cited blogpost: The slogan is that types are intensional , whereas…

Just my 2c here. I like the (A|B) syntax and I see me using it if available. The alternative with unicode characters I’ll never use. Having a unicode character in the code is not worth the trouble.

[image] Benny: Sets can be defined intensionally , especially convenient for infinite sets where we can’t just list all elements. And does it make sense to consider all types intensional? Well, considering sets extensionally makes a very strong statement: Two definitions create the same set if…

[image] foobar_lv2: Well, considering sets extensionally makes a very strong statement: Two definitions create the same set if they happen to have the same elements (“…in our model universe”). Types are intensional, in the sense that: Two definitions create the same type if there is a proof (…i…

[image] MilesCranmer: But I wonder if the majority of Julia veterans (who would have the most say) would also be in opposition or not. “Julia veteran” is a fuzzy term, but note that very few of the people who would actually decide this commented here, and I don’t see them being enthusiastic a…

[image] Tamas_Papp: FWIW, I would do what @mkitti recommends above , ie work out the details in a package, experiment with it for a while (>10k LOC), and then make a PR to Julia proper if it is absolutely necessary Totally agree here, and I wish there was an actual requirement for all proposed…

[image] aplavin: Totally agree here, and I wish there was an actual requirement for all proposed function/type additions to pass through this process! (aside from compiler/internals) Unfortunately, that’s far from being the case, but we can at least try (: It seems to me that this new syntac…

[image] aplavin: In this specific situation, create a small package like UnionSyntax.jl with: I hate to repeat myself from upthread, but this is an unequivocally terrible idea for packages. Pulling in a dependency is even worse than the type piracy, in terms of “weirdness tax” for tiny synta…

[image] foobar_lv2: I hate to repeat myself from upthread, but this is an unequivocally terrible idea for packages. You mean, to use it in major packages? Sure, better not to do that (: But to use in personal code, and to let others easily try the suggested syntax/functions? This approach wo…

[image] MilesCranmer: This is why I wondered if we should just make a PR about it so we can get the attention of the off-discourse folks. Apart from a few who are in strong opposition, I did sense an overall welcoming towards the idea (or a close variant) from a majority of the (self-selected) …

Proposed alias for union types

Internals & Design

Topic		Replies	Views
Syntactic sugar for types General Usage	8	343	September 22, 2024
Union Types - Good or Bad? Internals & Design	17	2642	September 9, 2020
[ANN] SumTypes.jl 0.1 Package Announcements	30	3505	January 26, 2021
Keeping the syntax and the need to memorise syntax simple Internals & Design	100	8134	September 7, 2022
A most harrowing collection of Julia WATs General Usage wat	108	12812	January 27, 2024

Proposed alias for union types

Related topics