On Saturday, 12 October 2013 at 14:03:26 UTC, Sönke Ludwig wrote:
I've made short roundup of the different features/requirements
that have been mentioned (may have forgotten some and added
some) as this thread has a complexity that presumably makes it
quite hard to follow for most readers. I have also attached an
estimated priority for each requirement based on the discussion
and my own experiences.
- Memory safety [very important but also very
difficult/limiting]
Disallow escaping uncounted references to reference counted
memory. Keywords: pure, scope, isolated/owned
We have a first missing block here :D
I do think this is mandatory.
- Objective-C compatible [important]
Weak references, manual memory management and autorelease
pools are
some keywords here
Can someone explain me what an autorelease pool is ?
- Handle reference cycles [nice to have]
Requires GC memory for storing the instances
The good new is that we can (and IMO should) layer ref counting
on top of GC. This is the only way to make both work nicely
together and have safety net for leakage.
- Weak pointers [critical]
Only briefly mentioned, but critical for many data
structures
(e.g. graphs or caches) requires external reference
counting
Easy for RefCounted but become tricky for GC stuff.
- Not require two separate counts for COM [mildly important]
Using GC memory would require a second reference count for
the
D side of things, which is not desirable for multiple
reasons
Can you explain that one a bit more ? Especially how it require 2
count.
- Support type qualifiers [critical]
All usual type qualifiers and conversions should work as
expected.
This is not possible in a pure template based solution.
Here we have the second piece missing. We need a way to tail
qualify template.
- Not require new annotations [important]
Getting this to work without introducing new
keywords/syntax is
strongly preferred by Walter
We have 2 missing bloc to make that work (from a language
perpective, many runtime/compiler magic is also required).
- Support OOP reasonably well [important]
The usual up and down casts should work and calling
functions of
base classes needs to be safe
I see no way to make that work without increasing the scope of
scope (huhuhu :P)
Please mention any points that I have forgotten so that we have
some kind of unit test against which proposed designs can be
checked.
You did an excellent job here. I guess we have 2 missing piece
(and an incomplete one in the name of scope) to get sorted out
and we can get something really nice here !
