On Sunday, 16 February 2014 at 02:57:25 UTC, Steven Schveighoffer wrote:
> On Sat, 15 Feb 2014 07:33:04 -0500, Jakob Ovrum <jakobovrum@gmail.com> wrote:
>
>> On Friday, 14 February 2014 at 15:56:16 UTC, Steven Schveighoffer wrote:
>>> Classes are typically written with an expectation that the GC will clean them up. I don't think you can just get rid of that expectation. A class written without the assumption of the runtime is a very different object, and I would be hesitant to name it 'class' in D.
>>>
>>> I recommend not supporting classes, at least for now.
>>>
>>> -Steve
>>
>> This applies to the `new` operator, not classes in general. Classes should be supported but not `new`.
>
> New is not the issue. The expectation, when I write my class, that it will be cleaned up by the GC, is the issue.
>
> I remember this little nugget of paradox from the documentation of classes:
>
> "This means that when the garbage collector calls a destructor for an object of a class that has members that are references to garbage collected objects, those references may no longer be valid. This means that destructors cannot reference sub objects. This rule does not apply to auto objects or objects deleted with the DeleteExpression, as the destructor is not being run by the garbage collector, meaning all references are valid."
>
> So if you can write your class such that it will always require manual deletion, it's OK to refer to other GC'd objects in the destructor. Otherwise, it's not. Oh, and the runtime doesn't tell you when you're in the GC :)
>
> This leads us to the fun problem:
>
> 1. Without a GC, a destructor is REQUIRED to clean up owned resources that were (likely) malloc'd.
> 2. With a GC, a destructor is REQUIRED to NOT clean up owned resources that were GC'd.
>
> How to write such a destructor?
>
> But, besides that point: most classes are written expecting the GC to be used. They might possibly not use the new expression internally (or any other banned expressions by this new feature), and therefore compile. However, the expectation when writing such a class is that the GC will clean up after it. It's more the code that isn't there, than code that is forbidden.
>
> If we allowed classes, we would have to have an "opt-in" mechanism, so one can indicate to the compiler that it can be used in this restricted mode (yes, compiler, I handle manual destruction properly).
>
> I think that the best and quickest approach at this time is to disallow classes. They are not trivial. If we can figure out a clean way to add them back, then they can be allowed later.
>
> -Steve

Note that the same applies to classes with ARC (or other reference counting mechanism).

+1 especially if it shows the amount allocated as well.
On 14 Feb 2014 21:10, "Kagamin" <spam@here.lot> wrote:

> I don't think, everything should be done by the compiler. Most trouble with gc is that its usage can't be traced similar to tls, so the feature will be diagnostics similar to -vtls option, say, -vminimal. The compiler can write the trace of runtime usage in machine-readable format to stdout (format: `vminimal:feature:file:line`) and a separate frontend (stylesop) can analyze the trace and apply arbitrary feature usage policy. Don't change semantics of language constructs. The first step would be to implement tracing of gc usage.
>

On Sat, 15 Feb 2014 23:53:19 -0500, Denis Koroskin <2korden@gmail.com> wrote:

> On Sunday, 16 February 2014 at 02:57:25 UTC, Steven Schveighoffer wrote:
>> I think that the best and quickest approach at this time is to disallow classes. They are not trivial. If we can figure out a clean way to add them back, then they can be allowed later.
>>
>
> Note that the same applies to classes with ARC (or other reference counting mechanism).

Right, but ARC classes would be marked differently or derive from a different base. Like extern(C++) classes (which actually should work under minimal D).

What we are debating is allowing just plain-old D classes could compile and be used under minimal D. I don't think that's a good idea.

-Steve

On Sunday, 16 February 2014 at 02:57:25 UTC, Steven Schveighoffer wrote:

> New is not the issue. The expectation, when I write my class, that it will be cleaned up by the GC, is the issue.
>
> I remember this little nugget of paradox from the documentation of classes:
>
> "This means that when the garbage collector calls a destructor for an object of a class that has members that are references to garbage collected objects, those references may no longer be valid. This means that destructors cannot reference sub objects. This rule does not apply to auto objects or objects deleted with the DeleteExpression, as the destructor is not being run by the garbage collector, meaning all references are valid."
>
> So if you can write your class such that it will always require manual deletion, it's OK to refer to other GC'd objects in the destructor. Otherwise, it's not. Oh, and the runtime doesn't tell you when you're in the GC :)
>
> This leads us to the fun problem:
>
> 1. Without a GC, a destructor is REQUIRED to clean up owned resources that were (likely) malloc'd.
> 2. With a GC, a destructor is REQUIRED to NOT clean up owned resources that were GC'd.
>
> How to write such a destructor?

In D1 Tango added a new method, "dispose", to Object. This method is called when an object is destroyed either when calling "delete" or when going out of scope for scope declared objects.

--
/Jacob Carlborg

On Sunday, 16 February 2014 at 11:43:22 UTC, Jacob Carlborg wrote:

> In D1 Tango added a new method, "dispose", to Object. This method is called when an object is destroyed either when calling "delete" or when going out of scope for scope declared objects.

Forgot to say, other GC objects are still valid when this method is called.

--
/Jacob Carlborg

On Sunday, 16 February 2014 at 05:27:07 UTC, Steven Schveighoffer wrote:
> On Sat, 15 Feb 2014 23:53:19 -0500, Denis Koroskin <2korden@gmail.com> wrote:
>
>> On Sunday, 16 February 2014 at 02:57:25 UTC, Steven Schveighoffer wrote:
>>> I think that the best and quickest approach at this time is to disallow classes. They are not trivial. If we can figure out a clean way to add them back, then they can be allowed later.
>>>
>>
>> Note that the same applies to classes with ARC (or other reference counting mechanism).
>
> Right, but ARC classes would be marked differently or derive from a different base. Like extern(C++) classes (which actually should work under minimal D).
>
> What we are debating is allowing just plain-old D classes could compile and be used under minimal D. I don't think that's a good idea.
>
> -Steve

Oh, sorry, I thought the were discussing extern(C++) classes support -- those are too GC'd by default so compiled with and without GC require different designs and implementations.

Plain objects require Object.d, core.Mutex, ModuleInfo, TypeInfo and a lot of other things to support, and as such most likely impossible to implement preserving compatibility with "full D".

On Thursday, 13 February 2014 at 23:14:20 UTC, 1100110 wrote:
> I think it's about time I gave back to this wonderful community.
>
> I'm offering a $50 bounty on this.
> (Preferably Bitcoins, but I'll use bountysource if desired.)
>
> rules:
> Has to be called -minimal
> Has to fulfill Walter's original post. (listed below)
> Has to split the separate parts into different flags as well as -minimal(-nogc, -nomoduleinfo, etc. Naming is left to the implementer).
>
>
> This seems to be a good idea and has lots of support from the community, would anyone like to chip in a few more bucks?
>
> I haven't set the bounty yet, depends on if multiple people chip in.  I'll probably set it sometime tonight.
>
> Let me know what y'all think, am I leaving anything out?
> Thanks
>
>
> On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
>> I've toyed with this idea for a while, and wondered what the interest there is in something like this.
>>
>> The idea is to be able to use a subset of D that does not require any of druntime or phobos - it can be linked merely with the C standard library. To that end, there'd be a compiler switch (-betterC) which would enforce the subset.
>>
>> (First off, I hate the name "better C", any suggestions?)
>>
>> The subset would disallow use of any features that rely on:
>>
>> 1. moduleinfo
>> 2. exception handling
>> 3. gc
>> 4. Object
>>
>> I've used such a subset before when bringing D up on a new platform, as the new platform didn't have a working phobos.
>>
>> What do you think?

Isn't this a bit premature?

The idea is controversial, if you read the thread Andrei and Walter wanted to postpone it:

>I convinced Walter of my view on this, so he won't work on it. I trust
that at least between the two of us we can focus on working on what
matters most first.
>
>Andrei

so why the hurry?


std.allocator should solve the biggest issue which is not making the GC mandatory, and then I don't see the point of stripping D of many of its essential features (classes, array operations, TLS, dynamic casts, static ctors and dtors, ...) when GDC and LDC are already able to enable them (i.e add parts of druntime and Phobos to the binary) on a per-needed basis when statically linking.

IMHO an approach that would not involve making a binary choice between "full D" and "minimal D" is to add an option to make the linker strip druntime and Phobos' shared libraries (or any shared library, and it's not specific to D btw) to the "lowest common denominator" required by a bunch of libraries and applications. Wouldn't that fulfill one of the two goals -nodruntime is trying to achieve as far as I understand (saving memory)?

And regarding the other goal, to help porting D to other platforms a stub druntime would be cleaner than a hackish compiler flag that requires many changes to DMD.

Am 16.02.2014 17:18, schrieb Elie Morisse:
> On Thursday, 13 February 2014 at 23:14:20 UTC, 1100110 wrote:
>> I think it's about time I gave back to this wonderful community.
>>
>> I'm offering a $50 bounty on this.
>> (Preferably Bitcoins, but I'll use bountysource if desired.)
>>
>> rules:
>> Has to be called -minimal
>> Has to fulfill Walter's original post. (listed below)
>> Has to split the separate parts into different flags as well as
>> -minimal(-nogc, -nomoduleinfo, etc. Naming is left to the implementer).
>>
>>
>> This seems to be a good idea and has lots of support from the
>> community, would anyone like to chip in a few more bucks?
>>
>> I haven't set the bounty yet, depends on if multiple people chip in.
>> I'll probably set it sometime tonight.
>>
>> Let me know what y'all think, am I leaving anything out?
>> Thanks
>>
>>
>> On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
>>> I've toyed with this idea for a while, and wondered what the interest
>>> there is in something like this.
>>>
>>> The idea is to be able to use a subset of D that does not require any
>>> of druntime or phobos - it can be linked merely with the C standard
>>> library. To that end, there'd be a compiler switch (-betterC) which
>>> would enforce the subset.
>>>
>>> (First off, I hate the name "better C", any suggestions?)
>>>
>>> The subset would disallow use of any features that rely on:
>>>
>>> 1. moduleinfo
>>> 2. exception handling
>>> 3. gc
>>> 4. Object
>>>
>>> I've used such a subset before when bringing D up on a new platform,
>>> as the new platform didn't have a working phobos.
>>>
>>> What do you think?
>
> Isn't this a bit premature?
>
> The idea is controversial, if you read the thread Andrei and Walter
> wanted to postpone it:
>
>> I convinced Walter of my view on this, so he won't work on it. I trust
> that at least between the two of us we can focus on working on what
> matters most first.
>>
>> Andrei
>
> so why the hurry?
>
>
> std.allocator should solve the biggest issue which is not making the GC
> mandatory, and then I don't see the point of stripping D of many of its
> essential features (classes, array operations, TLS, dynamic casts,
> static ctors and dtors, ...) when GDC and LDC are already able to enable
> them (i.e add parts of druntime and Phobos to the binary) on a
> per-needed basis when statically linking.
>
> IMHO an approach that would not involve making a binary choice between
> "full D" and "minimal D" is to add an option to make the linker strip
> druntime and Phobos' shared libraries (or any shared library, and it's
> not specific to D btw) to the "lowest common denominator" required by a
> bunch of libraries and applications. Wouldn't that fulfill one of the
> two goals -nodruntime is trying to achieve as far as I understand
> (saving memory)?
>
> And regarding the other goal, to help porting D to other platforms a
> stub druntime would be cleaner than a hackish compiler flag that
> requires many changes to DMD.

That is also my opinion.

On Sun, 16 Feb 2014 06:46:53 -0500, Jacob Carlborg <doob@me.com> wrote:

> On Sunday, 16 February 2014 at 11:43:22 UTC, Jacob Carlborg wrote:
>
>> In D1 Tango added a new method, "dispose", to Object. This method is called when an object is destroyed either when calling "delete" or when going out of scope for scope declared objects.
>
> Forgot to say, other GC objects are still valid when this method is called.

Right, but there is no obligation to follow this pattern. One is free to just not do anything, and the GC will clean up your garbage.

-Steve

On Sun, 16 Feb 2014 11:18:12 -0500, Elie Morisse <syniurge@gmail.com> wrote:

> Isn't this a bit premature?
>
> The idea is controversial, if you read the thread Andrei and Walter wanted to postpone it:
>
>> I convinced Walter of my view on this, so he won't work on it. I trust
> that at least between the two of us we can focus on working on what
> matters most first.
>>
>> Andrei
>
> so why the hurry?

It's not a rush, it's just that Walter has better things to do. But it doesn't mean the feature itself is controversial.

-Steve