does D already have too many language features ?
greatsam4sure at gmail.com
Tue Dec 31 15:23:02 UTC 2019
On Tuesday, 31 December 2019 at 00:39:01 UTC, H. S. Teoh wrote:
> On Mon, Dec 30, 2019 at 11:59:27PM +0000, GreatSam4sure via
> Digitalmars-d wrote: [...]
> +1, pay-as-you-go. I've been wanting this for a while now.
> Keep in mind, though, that using LDC with --gc-sections *does*
> in fact trim the fat down significantly. Only thing is, you
> need to be careful in how you configure it, and some code may
> break if they implicitly assume the existence of certain
> sections that aren't referred to directly (such code should be
> very rare, though, and whoever would write such code probably
> already knows not to use --gc-sections so it shouldn't be an
> actual problem in practice).
> I've tried this with dynamic libraries created for Android
> before, and it works like a charm (~1.3 MB bloated .so --> 400+
> KB with --gc-sections and a custom linker configuration file --
> and this is *with* a significant amount of Phobos usage, so
> we're not talking about straitjacketing yourself with -betterC
> I find myself wishing the same thing too, esp. when two
> features, when used together, interact (break :-P) in
> unexpected ways. Most recent example: Grapheme interacts
> badly with .map.
> OTOH, because D has so many features that have complex
> interactions, it's almost unavoidable to have some combination
> of features that nobody has put to use together before, or they
> haven't used it thoroughly enough to uncover the problem spots.
> The only thing I can propose here is, please file all such
> bugs to bugzilla so that they don't get forgotten. Maybe
> somebody should come up with a fuzzer specially geared for
> finding problematic combinations of features (seems hard to do,
> though, since it's not obvious how a set of randomly-picked
> features "ought" to interact and what the results should be, so
> you can't exactly automate such a thing).
> Have you seen Adam Ruppe's latest jni.d? Barring some current
> limitations, it lets you interoperate D code with Java via JNI
> almost in a transparent way. The fact that this is possible at
> all is absolutely amazing, and a testament to D's awesomeness,
> and I hope sometime in 2020 Adam will come up with a way to
> solve the remaining issues so that jni.d can become a general
> solution to D <-> Java interop. Just think of the huge amounts
> of Java class libraries that can be made available to D at the
> press of a button. This is HUGE.
Thanks for your patient and detail explanation for the issue at
The feature set of D is thoroughly awesome. I am amazed at how a
language of these feature sets can be simple to write, precise
and we'll readable with the raw power of C and C++. I am hoping
that the D community we know that they have a beautiful language
in there and maximize it to their language.
D is well ahead of most languages with great publicity out there.
What D need is through polishing not triming.
I am aware of Adam JNI but I have not really understand how to
apply it. I have ask for tutorial he is yet to reply
More information about the Digitalmars-d