June 15, 2020
On Monday, 15 June 2020 at 20:47:16 UTC, 12345swordy wrote:
> On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
>> https://code.dlang.org/packages/tardy
>> https://github.com/atilaneves/tardy
>>
>> [...]
> Wouldn't a top type be a better way to achieve this?
>
> -Alex

the Talias in type functions is a top type. (If I do understand correctly that it is something it's another word for an Any type.)
it's a pain in the ass, to work with if you are not dynamically typed language.
June 15, 2020
On Monday, 15 June 2020 at 20:51:38 UTC, Stefan Koch wrote:
> On Monday, 15 June 2020 at 20:47:16 UTC, 12345swordy wrote:
>> On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
>>> https://code.dlang.org/packages/tardy
>>> https://github.com/atilaneves/tardy
>>>
>>> [...]
>> Wouldn't a top type be a better way to achieve this?
>>
>> -Alex
>
> the Talias in type functions is a top type. (If I do understand correctly that it is something it's another word for an Any type.)
> it's a pain in the ass, to work with if you are not dynamically typed language.

Speaking of type functions, have you been working on a dip for that? I am quite curious to see what it looks like currently.
-Alex
June 15, 2020
On Monday, 15 June 2020 at 20:54:27 UTC, 12345swordy wrote:
> On Monday, 15 June 2020 at 20:51:38 UTC, Stefan Koch wrote:
>> On Monday, 15 June 2020 at 20:47:16 UTC, 12345swordy wrote:
>>> On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
>>>> https://code.dlang.org/packages/tardy
>>>> https://github.com/atilaneves/tardy
>>>>
>>>> [...]
>>> Wouldn't a top type be a better way to achieve this?
>>>
>>> -Alex
>>
>> the Talias in type functions is a top type. (If I do understand correctly that it is something it's another word for an Any type.)
>> it's a pain in the ass, to work with if you are not dynamically typed language.
>
> Speaking of type functions, have you been working on a dip for that? I am quite curious to see what it looks like currently.
> -Alex

Oh no, I haven't. And I am not really a visionary.
I am trying to solve a few concrete problems.
To language addition is a means to an end, for a DIP which is is supposed to consider the language at large, I would need help.

Furthermore, I have to see how the implementation plays out.
It would be unwise to spec something that I couldn't implement.

June 16, 2020
On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
> https://code.dlang.org/packages/tardy
> https://github.com/atilaneves/tardy
>

Looks interesting, nice work!

How does it compare to:
https://dlang.org/phobos/std_experimental_typecons#.wrap ?

In the more longer-term, is the goal of the project to implement a Typescript / Go interfaces like structural type system in user space? Also how would it compare to Rust traits? I guess the main difference, would be that Rust enforces a nominal type system like approach, where 2 differently named traits that otherwise define the same interface are not considered interchangeable.
June 16, 2020
On Monday, 15 June 2020 at 20:47:16 UTC, 12345swordy wrote:
> On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
>> https://code.dlang.org/packages/tardy
>> https://github.com/atilaneves/tardy
>>
>> [...]
> Wouldn't a top type be a better way to achieve this?
>
> -Alex

How?
June 16, 2020
On Tuesday, 16 June 2020 at 03:56:52 UTC, Petar Kirov [ZombineDev] wrote:
> On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
>> https://code.dlang.org/packages/tardy
>> https://github.com/atilaneves/tardy
>>
>
> Looks interesting, nice work!
>
> How does it compare to:
> https://dlang.org/phobos/std_experimental_typecons#.wrap ?

For starters, that uses a class and inheritance internally and therefore has all the drawbacks of that approach as laid out in tardy's README.md. Then there's the lack of allocator support.

> In the more longer-term, is the goal of the project to implement a Typescript / Go interfaces like structural type system in user space?

Yes. Other than allowing multiple interfaces, I think it's already implemented.

> Also how would it compare to Rust traits?

Rust's traits are usually used like D's template contraints and Haskell's type classes. The only way they're relevant here are trait objects:

https://doc.rust-lang.org/reference/types/trait-object.html

The main difference is that tardy is supposed to give the user choices over how the dispatch is actually implemented. Allocators alone are huge.

> I guess the main difference, would be that Rust enforces a nominal type system like approach, where 2 differently named traits that otherwise define the same interface are not considered interchangeable.

Yes, that's also a difference.


June 16, 2020
On Tuesday, 16 June 2020 at 09:15:10 UTC, Atila Neves wrote:
> On Tuesday, 16 June 2020 at 03:56:52 UTC, Petar Kirov [ZombineDev] wrote:
>> On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
>>> https://code.dlang.org/packages/tardy
>>> https://github.com/atilaneves/tardy
>>>
>>
>> Looks interesting, nice work!
>>
>> How does it compare to:
>> https://dlang.org/phobos/std_experimental_typecons#.wrap ?
>
> For starters, that uses a class and inheritance internally and therefore has all the drawbacks of that approach as laid out in tardy's README.md. Then there's the lack of allocator support.
>
>> In the more longer-term, is the goal of the project to implement a Typescript / Go interfaces like structural type system in user space?
>
> Yes. Other than allowing multiple interfaces, I think it's already implemented.

Cool!

>> Also how would it compare to Rust traits?
>
> Rust's traits are usually used like D's template contraints and Haskell's type classes. The only way they're relevant here are trait objects:

Yes I meant trait objects actually.

> https://doc.rust-lang.org/reference/types/trait-object.html
>
> The main difference is that tardy is supposed to give the user choices over how the dispatch is actually implemented. Allocators alone are huge.

Interesting!

>> I guess the main difference, would be that Rust enforces a nominal type system like approach, where 2 differently named traits that otherwise define the same interface are not considered interchangeable.
>
> Yes, that's also a difference.


June 16, 2020
On Tuesday, 16 June 2020 at 09:15:10 UTC, Atila Neves wrote:
> [snip]
>> In the more longer-term, is the goal of the project to implement a Typescript / Go interfaces like structural type system in user space?
>
> Yes. Other than allowing multiple interfaces, I think it's already implemented.

I'm not familiar with what Typescript does, but doesn't Go allow interfaces to be implemented by free-standing functions? That is a little bit more similar to open methods. This requires the type inherit from the interface and implement member functions.

>
>> Also how would it compare to Rust traits?
>
> Rust's traits are usually used like D's template contraints and Haskell's type classes. The only way they're relevant here are trait objects:
>
> https://doc.rust-lang.org/reference/types/trait-object.html
>
[snip]

Similar to above, aren't Rusts's trait objects defined using separate impl blocks, rather than as member functions.

---

I'm not that knowledgeable of Boost, but I see some similarities with Boost's type_erasure library. However, one main difference is that it is implemented with concepts, rather than the equivalent of interfaces. I would guess using interfaces has some benefits in terms of implementation since you know exactly what functions need to be called. Something like @models is very flexible, but that might be a downside.

June 16, 2020
On Tuesday, 16 June 2020 at 11:24:05 UTC, jmh530 wrote:
> On Tuesday, 16 June 2020 at 09:15:10 UTC, Atila Neves wrote:
>> [snip]
>>> In the more longer-term, is the goal of the project to implement a Typescript / Go interfaces like structural type system in user space?
>>
>> Yes. Other than allowing multiple interfaces, I think it's already implemented.
>
> I'm not familiar with what Typescript does, but doesn't Go allow interfaces to be implemented by free-standing functions?

So does tardy.

> That is a little bit more similar to open methods. This requires the type inherit from the interface and implement member functions.

There is no inheritance anywhere, otherwise that'd defeat the point of the library in the first place. I used interfaces because they exist and intuively make sense, and support classes because why not. Otherwise it could be just structs and other values with candidate UFCS functions.

> I'm not that knowledgeable of Boost, but I see some similarities with Boost's type_erasure library. However, one main difference is that it is implemented with concepts, rather than the equivalent of interfaces. I would guess using interfaces has some benefits in terms of implementation since you know exactly what functions need to be called. Something like @models is very flexible, but that might be a downside.

Using an interface means using familiar syntax with the added benefits of being able to write a signature like this:

int* fun(int*, int) @safe @nogc pure return scope const;

And then have all of those attributes and `this` modifiers used in the vtable function pointer declarations. Overloading and UFCS get dealt with naturally by usual language rules.
June 16, 2020
On Tuesday, 16 June 2020 at 11:31:14 UTC, Atila Neves wrote:
> On Tuesday, 16 June 2020 at 11:24:05 UTC, jmh530 wrote:
>> On Tuesday, 16 June 2020 at 09:15:10 UTC, Atila Neves wrote:
>>> [snip]
>>>> In the more longer-term, is the goal of the project to implement a Typescript / Go interfaces like structural type system in user space?
>>>
>>> Yes. Other than allowing multiple interfaces, I think it's already implemented.
>>
>> I'm not familiar with what Typescript does, but doesn't Go allow interfaces to be implemented by free-standing functions?
>
> So does tardy.

Sorry, I had not realized that. I took Go's interface example and converted it to D. Would this work with tardy?

```
import tardy;

interface IGeometry
{
    double area() @safe pure const;
    double perim() @safe pure const;
}
alias Geometry = Polymorphic!IGeometry;

struct Rect {
    double width, height;
}

struct Circle {
    double radius;
}

double area(Rect r) {
    return r.width * r.height
}

double perim(Rect r) {
    return  2 * r.width + 2 * r.height
}

double area(Circle c) {
    import std.math: PI;
    return PI * c.radius * c.radius
}

double perim(Circle c) {
    import std.math: PI;
    return 2 * PI * c.radius
}

void measure(IGeometry g) {
    import std.stdio: writeln;
    writeln(g);
    writeln(g.area);
    writeln(g.perim);
}

void main() {
    auto r = Rect(3.0, 4.0);
    auto c = Circle(5.0);

    r.Geometry.measure;
    c.Geometry.measure;
}
```

>
>> That is a little bit more similar to open methods. This requires the type inherit from the interface and implement member functions.
>
> There is no inheritance anywhere, otherwise that'd defeat the point of the library in the first place. I used interfaces because they exist and intuively make sense, and support classes because why not. Otherwise it could be just structs and other values with candidate UFCS functions.

Sorry, that was me being hasty. I was just concerned about the member functions part of it, which you said above is not a concern.