More radical ideas about gc and reference counting

[Manu via Digitalmars-d]

On 5 May 2014 14:09, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 5/4/14, 5:38 PM, Caligo via Digitalmars-d wrote:
>>
>> On Sun, May 4, 2014 at 12:22 AM, Andrei Alexandrescu via Digitalmars-d
>> <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
>> Here is an idea:  include new features in DMD/Phobos as soon as they
>> arrive, and make them part of the official binary release so that the
>> average D user can try them out.  Make sure they are marked as unstable,
>> and put a on/off switch on them (something like what Rust/Haskell have;
>> not a compiler switch).  If the feature receives no implementation bug
>> reports for X consecutive days AND no design bug reports for Y
>> consecutive days, then the feature is marked stable and officially
>> becomes part of DMD/Phobos.  The X and the Y can be decreased as D's
>> number of users increases over the years.  The whole idea is very much
>> like farming: you are planting seeds.  As the plants grow, some of them
>> will not survive, others will be destroyed, and some of them will take
>> years to grow.  In any case, you harvest the fruits when they are ready.
>>
>>   Here are good starting values for X and Y:
>> X = 90 days
>> Y = 180 days
>
>
> This is nice, but on the face of it it's just this: an idea on how other
> people should do things on their free time. I'd have difficulty convincing
> people they should work that way. The kind of ideas that I noticed are
> successful are those that actually carry the work through and serve as good
> examples to follow.

There's imperfect but useful pull requests hanging around for years,
extern(Obj-C) for instance, which may be useful as an experimental
feature to many users, even if it's not ready for inclusion in the
official feature list and support.
I suspect it's (experimental) presence would stimulate further
contribution towards D on iOS for instance; it may be an enabler for
other potential contributors.

What about AST macros? It seems to me that this is never going to be
explored and there are competing proposals, but I wonder if there's
room for experimental implementations that anyone in the community can
toy with?

UDA's are super-useful, but they're still lacking the thing to really
set them off, which is the ability to introduce additional boilerplate
code at the site of the attribute.

I reckon there's a good chance that creating a proper platform for
experimental features would also have an advantage for community
building and increase contribution in general. If new contributors can
get in, have some fun, and start trying their ideas while also being
able to share them with the community for feedback without fear
they'll just be shot down and denied after all their work... are they
not more likely to actually make a contribution in the first place?
Once they've made a single contribution of any sort, are they then
more likely to continue making other contributions in the future
(having now taken the time to acclimatise themselves with the
codebase)?

I personally feel the perceived unlikeliness of any experimental
contribution being accepted is a massive deterrence to making compiler
contributions in the first place by anyone other than the most serious
OSS advocates. I have no prior experience with OSS, and it's certainly
a factor that's kept me at arms length.