https://github.com/dlang/phobos/pull/5355

Andrei

On Thursday, 27 April 2017 at 19:57:52 UTC, Andrei Alexandrescu wrote:
> https://github.com/dlang/phobos/pull/5355
>
> Andrei

And then we'd probably need INoGCAllocator and ISharedNOGCAllocator...

On Thursday, 27 April 2017 at 20:04:32 UTC, Stanislav Blinov wrote:
> On Thursday, 27 April 2017 at 19:57:52 UTC, Andrei Alexandrescu wrote:
>> https://github.com/dlang/phobos/pull/5355
>>
>> Andrei
>
> And then we'd probably need INoGCAllocator and ISharedNOGCAllocator...

Wasn't one major selling point of compile time introspection / duck typing that we could stop using interfaces such... naming schemes?

On Thursday, 27 April 2017 at 23:12:48 UTC, Moritz Maxeiner wrote:
> On Thursday, 27 April 2017 at 20:04:32 UTC, Stanislav Blinov wrote:
>> On Thursday, 27 April 2017 at 19:57:52 UTC, Andrei Alexandrescu wrote:
>>> https://github.com/dlang/phobos/pull/5355
>>>
>>> Andrei
>>
>> And then we'd probably need INoGCAllocator and ISharedNOGCAllocator...
>
> Wasn't one major selling point of compile time introspection / duck typing that we could stop using interfaces such... naming schemes?

IAllocator is too high level an interface, it doesn't carry any information as to what type of memory it can allocate (so we can only assume unshared), and does or does it not use GC (so we can only assume GC).

If we are to devise types with allocators as members instead of type arguments, we need the additional information. Better to catch invalid assignment at compile time than to chase down how a stack allocator from one thread ended up in another.

On 04/27/2017 07:12 PM, Moritz Maxeiner wrote:
>
> Wasn't one major selling point of compile time introspection / duck
> typing that we could stop using interfaces such... naming schemes?

Not that I speak for everyone, but the way I see it, no, the duck typing aspect is just something that's to be tolerated. The real gold is simply being freed from both the rigid mess and the runtime costs of class/interface hierarchies. I wish we DID have to include some kind of "implements ForwardRange" or "enum _thisStructImplements_ForwardRange" or some such to declare a type actually intends to be a ForwardRange (or whatever) and isn't merely qualifying as one by coincidence.

On Friday, 28 April 2017 at 01:12:39 UTC, Nick Sabalausky (Abscissa) wrote:
> On 04/27/2017 07:12 PM, Moritz Maxeiner wrote:
>>
>> Wasn't one major selling point of compile time introspection / duck
>> typing that we could stop using interfaces such... naming schemes?
>
> Not that I speak for everyone, but the way I see it, no, the duck typing aspect is just something that's to be tolerated. The real gold is simply being freed from both the rigid mess and the runtime costs of class/interface hierarchies. I wish we DID have to include some kind of "implements ForwardRange" or "enum _thisStructImplements_ForwardRange" or some such to declare a type actually intends to be a ForwardRange (or whatever) and isn't merely qualifying as one by coincidence.

https://github.com/atilaneves/concepts

import concepts;

@models!(isForwardRange, MyType)
struct MyType { .... }


Atila

On 04/28/2017 01:09 PM, Atila Neves wrote:
>
> https://github.com/atilaneves/concepts
>
> import concepts;
>
> @models!(isForwardRange, MyType)
> struct MyType { .... }
>

Hmm, close, but if I'm reading the source right, it looks like a type doesn't have to use the UDA in order for isXXX or "static assert(models..." to be satisfied, which was the whole issue I had. (Also, it'd be nice if it didn't require both isXXX and checkXXX to be manually written, because given a checkXXX function, the isXXX function is just boilerplate.)

Although I guess the checkXXX function could simply include a check the the UDA. Be nice if that was taken care of automatically though. Now if only we could get Phobos to do that...

I do, however, like the improved diagnostics this offers, and the fact that the checkXXX function uses a much saner (simpler, easier to read/remember/understand) syntax than the usual `is(typeof((){ ... })))` mess. I may use this.

On Friday, 28 April 2017 at 17:09:22 UTC, Atila Neves wrote:
>
> https://github.com/atilaneves/concepts
>
> import concepts;
>
> @models!(isForwardRange, MyType)
> struct MyType { .... }
>
>
> Atila

I remember you had posted about this last year. It looks like you've added some stuff on ranges to it recently...interesting.

You might want to include an example in the Readme.md of using the concept as a template constraint for a function. Maybe like

void callfoo(T)(T x)
	if (isFoo!T)
{
	x.foo();
}

Foo foo;
callfoo(foo);

On Friday, 28 April 2017 at 18:04:06 UTC, jmh530 wrote:
> On Friday, 28 April 2017 at 17:09:22 UTC, Atila Neves wrote:
>>
>> https://github.com/atilaneves/concepts
>>
>> import concepts;
>>
>> @models!(isForwardRange, MyType)
>> struct MyType { .... }
>>
>>
>> Atila
>
> I remember you had posted about this last year. It looks like you've added some stuff on ranges to it recently...interesting.
>
> You might want to include an example in the Readme.md of using the concept as a template constraint for a function. Maybe like
>
> void callfoo(T)(T x)
> 	if (isFoo!T)
> {
> 	x.foo();
> }
>
> Foo foo;
> callfoo(foo);

Done. I also added to the README that it has its own versions of the range constraints from Phobos that can be used with `@models`.

Atila

On 04/27/2017 04:04 PM, Stanislav Blinov wrote:
> On Thursday, 27 April 2017 at 19:57:52 UTC, Andrei Alexandrescu wrote:
>> https://github.com/dlang/phobos/pull/5355
>>
>> Andrei
>
> And then we'd probably need INoGCAllocator and ISharedNOGCAllocator...

"shared" is a type qualifier essentially changing the type of the interface, so a separate interface is needed. For @nogc, simple variance is sufficient:

interface A
{
    void fun();
}

class B : A
{
    void fun() @nogc {}
}

That said, there are quite a few functions we should be able to qualify as @nogc from the get-go, e.g. empty, expand, alignment etc. Would you like to try a PR to that effect? Thanks!


Andrei