On Wednesday, 4 April 2018 at 15:18:30 UTC, Andrei Alexandrescu wrote:
> On 04/04/2018 09:18 AM, 12345swordy wrote:
>> On Wednesday, 4 April 2018 at 04:49:10 UTC, Andrei Alexandrescu wrote:
>>> I'm working on a simple older idea to get it out of the way in preparation for the more difficult DIPs to come:
>>>
>>> https://github.com/andralex/DIPs/blob/ProtoObject/DIPs/DIPxxxx.md
>>>
>>> This is not officially reviewable yet, but conveys the gist and could use some early feedback. Any insight will be appreciated.
>>>
>>>
>>> Thanks,
>>>
>>> Andrei
>> 
>> No attempts to make class deallocation @nogc attribute friendly? This is a major PIA for me. The current attempts at this involve various workarounds (See automem library for example), which even then does not solve all the problems it currently have.
>
> Can you please give more detail on that? You mean the destructor of Object is automatically generated with a bad signature?
There is a bug report already on this.
https://issues.dlang.org/show_bug.cgi?id=15246

On Wednesday, 4 April 2018 at 15:18:30 UTC, Andrei Alexandrescu wrote:
> On 04/04/2018 09:18 AM, 12345swordy wrote:
>> No attempts to make class deallocation @nogc attribute friendly? This is a major PIA for me. The current attempts at this involve various workarounds (See automem library for example), which even then does not solve all the problems it currently have.
>
> Can you please give more detail on that? You mean the destructor of Object is automatically generated with a bad signature?

I assume this is what was meant:
https://issues.dlang.org/show_bug.cgi?id=15246

--
  Simen

On Wednesday, April 04, 2018 14:47:03 Luís Marques via Digitalmars-d wrote:
> Regarding the output range replacing toString. That's an obvious improvement. Yet, before that is set in stone, give the following at least some thought. I've always wondered about the use of output ranges. Yes, they can be more convenient to implement than input ranges, but they are less convenient to use because they are not composable (unless you create some kind of adapter Fiber that makes them input ranges). For instance, if you want to print an Object to the terminal with some color, you can't use a chain of ranges like `yourObject.toString.colorizer`, you have to output to some intermediary buffer. Just by coincidence, yesterday I was once again wondering about this and I decided to prototype an input-range-based formatter.  By restricting the initial version to a compile-time format string it actually made it *very* easy to implement a MVP. You basically just std.range.chain the first formatter item range and the remaining tail. And you can implement it piecemeal by using sformat to format integers/floats; this (temporarily) requires a small buffer in the range, but avoids the unbounded memory allocation for the stringy parts of the formatting (the literals, etc.), which is the truly problematic part.

In general, toString's API needs to work with functions like format and to!string. If improvements need to be made to those functions, then they can and should be, but in principle, by having ProtoObject, it's then possible for a class to implement toString however it wants. It puts toString on classes in pretty much the same boat that toString on structs is. The main difference is that any classes derived from that class then needs to worry about how their particular base class declared toString, and part of that then is whether the function was declared as a virtual function or a templated function. Now, declaring a useful toString that doesn't return string gets a bit more entertaining with classes due to the fact that a templated function isn't virtual, but each class hierarchy can then deal with that in the best way for it rather than one particular solution being pushed onto every class.

- Jonathan M Davis

On Wednesday, 4 April 2018 at 14:47:03 UTC, Luís Marques wrote:
> Regarding the output range replacing toString. That's an obvious improvement. Yet, before that is set in stone, give the following at least some thought.

It's a bit late for that ;) https://github.com/dlang/phobos/pull/5991

> For instance, if you want to print an Object to the terminal with some color, you can't use a chain of ranges like `yourObject.toString.colorizer`, you have to output to some intermediary buffer. Just by coincidence, yesterday I was once again wondering about this and I decided to prototype an input-range-based formatter.  By restricting the initial version to a compile-time format string it actually made it *very* easy to implement a MVP.

The counter to this is that output ranges are only for finalizing data that you want to buffered. In the example given, yourObject should instead have a range generating function which can be given to colorizer, which is then given to stdout.lockingTextWriter.