Menu
Search

Forums

Forum Index

December 03, 2022
Gravatar of Basile B.Posted by Basile B.
in reply to H. S. Teoh		Reply
Basile B.
Gravatar of Basile B.
Posted in reply to H. S. Teoh


Reply
On Saturday, 3 December 2022 at 17:50:19 UTC, H. S. Teoh wrote:
> On Sat, Dec 03, 2022 at 05:26:41PM +0000, Basile B. via Digitalmars-d wrote: [...]
>> [...]
>
> I don't follow.  Whether or not the sum type is built into the language, the tag has to be stored *somewhere*, your struct size will not be compatible with C regardless.  Just because .a uses a built-in sumtype does not make the tag disappear into thin air, it will still exist in the struct and occupy space, and the result is still not compatible with C because C does not understand sumtypes.
>
> Either way, on the C side you have to declare the tag explicitly and deal with it explicitly, regardless of whether sumtypes are built into the language or not.
>
>
> T

I dont want `?.` to be related to that, which was proposed at the very beginning of this fork. Since the very beginning of this fork I explain that `ident?.` is something else.
December 04, 2022
Gravatar of rikki cattermolePosted by rikki cattermole
in reply to John Colvin		Reply
rikki cattermole
Gravatar of rikki cattermole
Posted in reply to John Colvin


Reply
Its worth remembering that sum types and tuples are both foundational in type theory. Getting these into the language allow for the language to be a lot more foundationally stable in its design.

And thats coming from someone who has been screaming about DllImport being incomplete in dmd and running into issues about that almost daily (ok not daily because I have written off dmd until its fixed) and all the while working on a DIP for value type exceptions lol.
December 03, 2022
Gravatar of ryuukk_Posted by ryuukk_
in reply to rikki cattermole		Reply
ryuukk_
Gravatar of ryuukk_
Posted in reply to rikki cattermole


Reply
On Saturday, 3 December 2022 at 22:55:47 UTC, rikki cattermole wrote:
> Its worth remembering that sum types and tuples are both foundational in type theory. Getting these into the language allow for the language to be a lot more foundationally stable in its design.


I agree with this 100%! Let's not get ourselves distracted, there are issues that needs to be resolved, sure, but we should not forget about the importance of having sumtype/tuple right
December 04, 2022
Gravatar of zjhPosted by zjh
in reply to John Colvin		Reply
zjh
Gravatar of zjh
Posted in reply to John Colvin


Reply

On Saturday, 3 December 2022 at 16:17:19 UTC, John Colvin wrote:

>

On Tuesday, 29 November 2022 at 06:26:20 UTC, Walter Bright wrote:

>

Go ahead, Make My Day! Destroy!

https://github.com/WalterBright/DIPs/blob/sumtypes/DIPs/1NNN-(wgb).md

I don’t want to be discouraging of good work, but D is not lacking in great features, it is lacking in its implementation of the basics.

I have come to believe over several years working in D, managing work in D at some scale (10s of devs, not 100s) & advocating for D that the foundations are shaky and crumbly and need work.

While it is not possible to implement a struct as drop-in replacement for a built in slice, while template symbol emission bugs keep happening[1], while the built in AAs are not in great shape (and the signature of toHash is a PITA), while the compiler is a huge memory hog and compile times for templates get wild, while speculative compilation results somehow go wrong and leak in to the non-speculative parts of compilation (e.g. https://issues.dlang.org/show_bug.cgi?id=19545), while syntax changes happen without enough noise (so even basic tooling ends up breaking), while shared and property and synchronised classes and so on sit in poor and/or incomplete shape, while delegate contexts still have qualifier problems[2]…

Why would the limited resources available be focused on a built-in sum type?

You should make a list sort by importance.

December 04, 2022
Gravatar of zjhPosted by zjh
in reply to zjh		Reply
zjh
Gravatar of zjh
Posted in reply to zjh


Reply

On Sunday, 4 December 2022 at 01:39:26 UTC, zjh wrote:

>

You should make a list sort by importance.

D needs to explain the d core and internal mechanism in more detail! Then others will know how to modify it! And not the personal project of the d author.
It is better to have a text version of the detail.

December 05, 2022
Gravatar of KagaminPosted by Kagamin
in reply to Walter Bright		Reply
Kagamin
Gravatar of Kagamin
Posted in reply to Walter Bright


Reply
Query expression probably overlaps with pattern matching. Maybe use keyword based syntax? `if(case(result.Error))...`
December 05, 2022
Gravatar of KagaminPosted by Kagamin
in reply to Quirin Schroll		Reply
Kagamin
Gravatar of Kagamin
Posted in reply to Quirin Schroll


Reply

On Wednesday, 30 November 2022 at 14:33:51 UTC, Quirin Schroll wrote:

>

I wanted to write something like this in my post, but it really didn’t fit. As for enum, can’t semicolon syntax just be added? Can’t we just both allow enum X { A; B; } and enum { A, B }? (We don’t need to deprecate the comma syntax, it works fine except when it’s a hindrance. It’s not evil.)

This. Now we have doc comments and UDAs attached to enum members, it's too much for measly comma syntax.

December 05, 2022
Gravatar of Jacob ShtokolovPosted by Jacob Shtokolov
in reply to Quirin Schroll		Reply
Jacob Shtokolov
Gravatar of Jacob Shtokolov
Posted in reply to Quirin Schroll


Reply

On Wednesday, 30 November 2022 at 14:20:31 UTC, Quirin Schroll wrote:

>

On Tuesday, 29 November 2022 at 06:26:20 UTC, Walter Bright wrote:

>

Go ahead, Make My Day! Destroy!
  1. As for a keyword, you could circumvent the problem by re-using existing keywords. enum union would be a candidate.

+1 for not introducing new keywords for such a feature. The sum type (or tagged union) in the current DIP looks somewhat like an extended union, so either combination of keywords containing union will work just great IMO.

If there is an urge to add new keywords, it could be like:

tagged union Option(T)
{
    None,
    T val
}

or maybe union alias or something like that.

Another essential and already mentioned feature is extensibility: imagine we have a typed event bus of the following configuration:

alias Events = SumType!(Connected, Disconnected, TextMessage);

Now we want to extend it with new types of events without losing support in the parts of the code we don't control (e.g. library code, etc.). How would we do that?

One thing would be to redefine the type by hand: it works great when the number of options is low, but what if there are tens or maybe hundreds of types?

Right now it's only possible by using classes, or by introducing a struct with discriminator/tag and a union field manually checking (and casting) the types at runtime.

Also, as the current proposal implements the algebraic data type as a C-style union rather than a type alias (or something like that), giving an explicit name to each tag in the union may be overwhelming if there are many types to be included.

December 05, 2022
Gravatar of Paul BackusPosted by Paul Backus
in reply to Jacob Shtokolov		Reply
Paul Backus
Gravatar of Paul Backus
Posted in reply to Jacob Shtokolov


Reply

On Monday, 5 December 2022 at 14:17:47 UTC, Jacob Shtokolov wrote:

>

Another essential and already mentioned feature is extensibility: imagine we have a typed event bus of the following configuration:

alias Events = SumType!(Connected, Disconnected, TextMessage);

Now we want to extend it with new types of events without losing support in the parts of the code we don't control (e.g. library code, etc.). How would we do that?

[...]

Right now it's only possible by using classes, or by introducing a struct with discriminator/tag and a union field manually checking (and casting) the types at runtime.

IMO if you want this kind of extensibility, a sum type is the wrong tool for the job. This is exactly the use case that classes are designed for: extending existing code to operate on new types, without modifying the code itself.

Sum types, by contrast, excel when the set of types is fixed, but you would like to be able to define new operations on that set of types without changing existing code.

December 05, 2022
Gravatar of KagaminPosted by Kagamin
in reply to rikki cattermole		Reply
Kagamin
Gravatar of Kagamin
Posted in reply to rikki cattermole


Reply
On Saturday, 3 December 2022 at 22:55:47 UTC, rikki cattermole wrote:
> Its worth remembering that sum types and tuples are both foundational in type theory. Getting these into the language allow for the language to be a lot more foundationally stable in its design.

Plenty of safe languages don't have sum types and sky doesn't fall.
« First   ‹ Prev
… 2 3 4 5 6 7 8 9 10 11 12 13
Next ›   Last »