std.experimental.allocator and @nogc

[ZombineDev via Digitalmars-d]

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:

// 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);
}

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);

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.