Disable GC entirely

[Dmitry Olshansky]

09-Apr-2013 23:39, Rob T пишет:
> On Tuesday, 9 April 2013 at 18:38:55 UTC, Dmitry Olshansky wrote:
> [...]
>>
>> All of this should be CUSTOMIZABLE and DECOUPLED! Give people the
>> frigging control over the OOP breed they want to use.
>>
>> Providing people a toolkit not a one-button black box (and that button
>> keeps getting stuck!) would be awesome.
>>
>
> What we have is a traditional monolithic language and compiler which is
> rather inflexible and not as useful as it could be if it were instead a
> library of components that you can pick and choose from to assemble the
> language sub-set and compiler components that you need for a particular
> application. If you don't like a component, you should be able to plug a
> different one in or write your own.
>

Love the positive radical nature of your post ;)

But - it can't hot swap components, it would break guarantees: say 
library expect Ref-Counted objects and you hot-swapped that for GC ones, 
and so and so forth.

The sane way is sub-setting by restrictions - no changes and no extras.
At least you can use the libraries if your set of restictions is 
superset of theirs.

> Same with the features of the language. I should be able to say "No I
> don't want dynamic arrays" in this part of my code and the compiler will
> refuse to compile them in.

Fine and nice. See threads about nogc.

> Perhaps I should even be able to create my
> own language features that natively compile.

Too bad and doesn't scale. Sub-setting works pulling custom built-ins 
doesn't. What could work is seeking smaller sets of "meta" or "proto" 
features in which we can implement others (in std-lib) at no loss in 
expressiveness, performance etc.

I claim that the whole OOP should be the first one to be broken down 
into few smallish proto-features. But as a start we'd better fix the AA 
in library disaster (by completing the move) though.



-- 
Dmitry Olshansky