On Saturday, 15 February 2014 at 04:13:49 UTC, 1100110 wrote:
> 1. Disable Garbage Collector   (suggestion: -nogc)

https://github.com/D-Programming-Language/dmd/pull/1886

> 3. Disable ModuleInfo          (suggestion: -nomoduleinfo)

dmd -betterC though note https://d.puremagic.com/issues/show_bug.cgi?id=11881

> 5. Disable linking of druntime (suggestion: -nodruntime)

dmd -defaultlib= -debuglib=

On 2/14/14, 22:20, Adam D. Ruppe wrote:
> On Saturday, 15 February 2014 at 04:13:49 UTC, 1100110 wrote:
>> 1. Disable Garbage Collector   (suggestion: -nogc)
>
> https://github.com/D-Programming-Language/dmd/pull/1886
Oh dmd! Why won't you build on my computer!?  Why!?

>
>> 3. Disable ModuleInfo          (suggestion: -nomoduleinfo)
>
> dmd -betterC though note
> https://d.puremagic.com/issues/show_bug.cgi?id=11881

Needs a name that describes what it does, and also needs to be documented.  I knew it existed, but I'm a little fuzzy on what all it actually does.  Is it just ModuleInfo, or...?

>
>> 5. Disable linking of druntime (suggestion: -nodruntime)
>
> dmd -defaultlib= -debuglib=
>
I thought that was for the stdlib, not the runtime?

See? Now I know even less than I did before!
Sigh.

On Saturday, 15 February 2014 at 04:34:30 UTC, 1100110 wrote:
> Is it just ModuleInfo, or...?

Yeah, that's pretty much all it actually does, and it isn't quite complete - array bounds checking for example won't work because they depend on module info.

But I don't think they should depend on it anyway, regardless of compiler switches.

> I thought that was for the stdlib, not the runtime?

They're the same thing when they are build - druntime and phobos are compiled together into phobos.lib. So turning them off means it won't link it.

Then if you provide an object.d in your local directory, it won't even try to load any of the regular druntime. This is how I did it in my minimal.zip.

On 2/14/14, 22:44, Adam D. Ruppe wrote:
> On Saturday, 15 February 2014 at 04:34:30 UTC, 1100110 wrote:
>> Is it just ModuleInfo, or...?
>
> Yeah, that's pretty much all it actually does, and it isn't quite
> complete - array bounds checking for example won't work because they
> depend on module info.
>
> But I don't think they should depend on it anyway, regardless of
> compiler switches.
>
>> I thought that was for the stdlib, not the runtime?
>
> They're the same thing when they are build - druntime and phobos are
> compiled together into phobos.lib. So turning them off means it won't
> link it.
Damn.  I *knew* that.  I remember reading about it when linux was getting shared lib support.

>
> Then if you provide an object.d in your local directory, it won't even
> try to load any of the regular druntime. This is how I did it in my
> minimal.zip.

Oh good.  Then what I actually want is for -betterC to be cleaned up and renamed (and Documented!), add compiler flags for no exceptions, no Object, and a way to turn the silent and link failures into compiler errors.



1) array concats. use the module memory.d instead (link failure)
2) module constructors and destructors (silent failure)
3) looping ModuleInfo without libc or bare metal (silent failure)
4) TLS variables. always use __gshared (runtime crash)
5) threads.
6) unittests (silent failure)

On Saturday, 15 February 2014 at 04:55:32 UTC, 1100110 wrote:
> Then what I actually want is for -betterC to be cleaned up and renamed (and Documented!)

BTW I did *not* actually use -betterC for my minimal.zip. I've been playing with it a bit recently to make an even more minimal thing, but I'm fairly happy with how the first try turned out: it runs on bare (x86) metal and the test binary is < 30 KB in size. That's really not too bad: most the language works and some of the parts that don't can be fixed for small cost too.

Up from the 5 KB I have going with the -betterC thing and my TypeInfo patches locally (or the 3 KB with no runtime at all, but that means no structs either which massively sucks) but 30 KB isn't really that large and IMO the other parts of the language are worth it. Classes and exceptions are cool.

> 2) module constructors and destructors (silent failure)

What we should get is RTInfo for modules. Why? Then you can have a library module scan the modules for static ctor/dtors and issue a static assert failure. No compiler switch needed, we can do custom project rules. Works in regular D too, totally awesome.

Daniel Murphy, el 14 de February a las 22:10 me escribiste:
> "1100110"  wrote in message news:tjgimnoqoflzrcrlwjws@forum.dlang.org...
> 
> >I'm offering a $50 bounty on this.
> >(Preferably Bitcoins, but I'll use bountysource if desired.)
> 
> I'd say just put it on bountysource, because then there's more chance others will add to it.
> 
> >
> >rules:
> >Has to be called -minimal
> 
> Dealbreaker.  The description for the switch reads "prevents all use of features which rely on druntime" and therefore the only reasonable switch name is "-nodruntime" or a variation of that.

-nort for short :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
Ideas claras, libertad y patriotismo, para mejorar la calidad de vida;
claro que todo con mucha calidad, porque, joven, ideas claras, libertad
o patriotismo tiene cualquiera.
	-- Ricardo Vaporeso

On 2014-02-15 05:55, 1100110 wrote:

> 6) unittests (silent failure)

These should be kept since they can be accessed with __traits(getUnitTests)

-- 
/Jacob Carlborg

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`.

On 2/15/14, 4:52, Jacob Carlborg wrote:
> On 2014-02-15 05:55, 1100110 wrote:
>
>> 6) unittests (silent failure)
>
> These should be kept since they can be accessed with __traits(getUnitTests)
>


Awesome!

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