std.experimental.allocator and @nogc

[rikki cattermole via Digitalmars-d]

On 09/05/2016 11:56 PM, ZombineDev wrote:
> On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole wrote:
>> On 09/05/2016 11:12 PM, ZombineDev wrote:
>>> On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole wrote:
>>>> I've done windowing and image libraries before.
>>>> You are correct, you do not need OOP.
>>>>
>>>> But if you want to keep implementation nicely separated out from
>>>> usage, you really do. Which is a major part of my requirements.
>>>
>>> Well, in my example above, everything is nicely separated, easy to use,
>>> yet quite flexible. And still there is no Java-style OOP. Do you have
>>> any examples, where the use of classic OOP would provide a strictly
>>> superior design?
>>
>> You're using templates. While this might be ok for image library.
>> I cannot use this for the windowing library. The implementation may
>> not be known and must be plugable at runtime.
>> The reality is, just because you say you know about something at
>> compile time doesn't mean the system that runs a program does.
>
> I'm still not convinced. You have a fixed at CT number of
> implementations. Even if you don't know at CT the actual platform that
> will be used, you can still choose at RT the correct template. Example:

You do not.
Shared libraries remember them?

> // platform name can be "X11", "mir", "Wayland", etc.
> auto getPlatformWindow(CTArgs...)(string platformNameRTArg)
> {
>     switch (platformNameRTArg.toLower)
>     {
>         default:
>              enforce(false, "Unknown platform: " ~ platformNameRTArg);
>
>         foreach (platform; EnumMembers!Platform)
>             case name.stringof:
>                  // Use std.experiment.typecons.Wrap if you need a
> common type.
>                  return getWindow!(name, CTArgs);
>     }
>     assert (0);
> }

Platform is undefined, did you mean IPlatform?

> But that's besides the point. Even with OOP, your return type can be an
> interface that has template parameters like allocators, policies, etc.
> You're providing some the arguments at CT and the rest of the return
> type is dynamically polymorphic. E.g.:
>
> interface Window(Allocator, Policy);
> Window!(Allocator, Policy) getWindow(alias allocator, Policy)(RunTimeArgs);

Sure you can, but now you have added another layer of indirection 
between implementation and usage because you can't use templated types 
in between.

> My point is that there's no need for IAllocator, even if you want to use
> OOP so badly.
> But in most cases you will either write different code for different
> platforms, making interfaces unnecessary, or you would be able to hide
> the differences behind a struct.
>
> And when the allocator and the other policies are template parameters
> you will know at CT that your code is @nogc.

Again, no templates. You cannot initialize them at runtime, and since 
you won't know all implementations until it executes, well, you've got a 
problem.
Its a many to many problem. I faced this with Cmsed as well.