On Sunday, 19 October 2014 at 10:45:31 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 19 October 2014 at 09:04:59 UTC, eles wrote:
I mostly agree with all that you are saying, still I am aware
that much effort and coordination will be needed. OTOH, this
would give D (and/aka the future of computing) a non-negligeable
edge (being able to optimize across libraries).
Some binary format allow extra meta-info, so it is possible… in
the long term.
Debug builds could be re-used for that, with some minor
modifications, I think.
Another idea would be to simply make the in and out contracts
of a function exposed in the corresponding .di file, or at
least a part of them (we could use "public" for those).
That's an option. Always good to start with something simple,
but with an eye for a more generic/powerful/unified solution in
the future.
I think it would not turn that bad. For the time being, putting
the contracts in the .di files would cost barely nothing (but
disk space). And, progressively, the compiler could be made to
integrate those, when the .di files with contracts are available,
in order to optimize the builds. It would be directly D code, so
very easily to interpret. Basically, the optimizer would have the
set of the asserts that limit the behaviour of that function at
his hand.
Anybody else who would like to comment on this?
But D3
People here traditionally don't like that word, but it has been
unleased several times on the forum. Maybe not that stringent
need, but I think that a somewhat disruptive "clean, clarify and
fix glitches and bad legacy" release of D(2) is more and more
needed and quite accepted as a good thing by the community (which
is ready to take the effort to bring code up to date).
