August 24, 2017
On Wednesday, 23 August 2017 at 17:43:27 UTC, Steven Schveighoffer wrote:
> I thought "closure" means allocating the stack onto the heap so you can return the delegate with its context intact.

I understood closure as capture of variables from external context. They are divided into upward closures and downward closures, the former needs heap allocation.
August 24, 2017
On 2017-08-24 02:55, H. S. Teoh via Digitalmars-d-announce wrote:

> One thing that would help is if things like TypeInfo, ModuleInfo, etc.,
> are only emitted on-demand

I think that would be quite difficult if we want to keep all the existing features. Combining separate compilation, runtime reflection and similar features make it difficult to know when a Type/ModuleInfo is used.

-- 
/Jacob Carlborg
August 24, 2017
On Thursday, 24 August 2017 at 03:31:02 UTC, Swoorup Joshi wrote:
> On Wednesday, 23 August 2017 at 17:44:31 UTC, Jonathan M Davis wrote:
>> On Wednesday, August 23, 2017 13:12:04 Mike Parker via Digitalmars-d- announce wrote:
>>> [...]
>>
>> I confess that I tend to think of betterC as a waste of time. Clearly, there are folks who find it useful, but it loses so much that I see no point in using it for anything unless I have no choice. As long as attempts to improve it don't negatively impact normal D, then I don't really care what happens with it, but it's clearly not for me.
>>
>> And it _is_ possible to use full-featured D from C/C++ when D does not control main. It's just more of a pain.
>>
>> - Jonathan M Davis
>
> Totally agree with this.

I disagree, I believe BetterC is worth the time.
August 24, 2017
On 23 August 2017 at 19:44, Jonathan M Davis via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> On Wednesday, August 23, 2017 13:12:04 Mike Parker via Digitalmars-d- announce wrote:
>> To coincide with the improvements to -betterC in the upcoming DMD 2.076, Walter has published a new article on the D blog about what it is and why to use it. A fun read. And I'm personally happy to see the love this feature is getting. I have a project I'd like to use it with if I can ever make the time for it!
>>
>> The blog:
>>
>> https://dlang.org/blog/2017/08/23/d-as-a-better-c/
>>
>> Reddit: https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/
>
> I confess that I tend to think of betterC as a waste of time. Clearly, there are folks who find it useful, but it loses so much that I see no point in using it for anything unless I have no choice. As long as attempts to improve it don't negatively impact normal D, then I don't really care what happens with it, but it's clearly not for me.
>
> And it _is_ possible to use full-featured D from C/C++ when D does not control main. It's just more of a pain.
>

It's getting better, there are certainly some tough topics that need to be addressed in the compiler implementation.

The GDC camp concurs with the sentiment of betterC being a waste of time.  My particular stance on the matter is that it should not be an all or nothing switch, granular control is fine.  The compiler should (and can!) produce a very small footprint whilst using the expressive richness of the language.

For instance, a D project targeting STM board, makes heavy use of classes and templates, resultant code segment is 3k.

https://github.com/JinShil/stm32f42_discovery_demo#the-good

I quote the author here that when building the project, there is:

"""
No Stinking -betterC. If you don't want the overhead of a certain
feature of D, don't use it. -betterC is just a synonymn for -worseD.
"""
August 24, 2017
On Thu, Aug 24, 2017 at 08:13:29PM +0200, Iain Buclaw via Digitalmars-d-announce wrote: [...]
> The GDC camp concurs with the sentiment of betterC being a waste of time.  My particular stance on the matter is that it should not be an all or nothing switch, granular control is fine.  The compiler should (and can!) produce a very small footprint whilst using the expressive richness of the language.
> 
> For instance, a D project targeting STM board, makes heavy use of classes and templates, resultant code segment is 3k.
> 
> https://github.com/JinShil/stm32f42_discovery_demo#the-good
> 
> I quote the author here that when building the project, there is:
> 
> """
> No Stinking -betterC. If you don't want the overhead of a certain
> feature of D, don't use it. -betterC is just a synonymn for -worseD.
> """

To be fair, though, the above-mentioned project did have to create a stub druntime in order to get things to work.  Not everyone may have the know-how required to construct a minimal druntime that works for their purposes.


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley
August 24, 2017
On 8/23/2017 5:35 PM, Michael V. Franklin wrote:
> Consider this:  Rust doesn't need a special switch to make it interoperable with C.  What's wrong with D's implementation that requires such things?  Granted, D is not Rust, but D's implementation could be improved to make it more competitive with Rust in these use cases.  For example, there is really no need for TypeInfo if you're not doing any dynanmic casts, but the current implementation generates it regardless.

There is a PR to make it only on demand,

  https://github.com/dlang/dmd/pull/6561

but it is mired in problems that are not in the D test suite and for which no test cases exist.

> I find -betterC to be somewhat of a copout for avoiding the hard work of improving D's implementation.

On the contrary, I view it as providing motivation for dealing with those issues. The PR above is stalled for lack of motivation.

---

Another issue is asserts. -betterC redirects them to C's assert. Perhaps we should abandon D's asserts? -betterC provides motivation to examine that.
August 24, 2017
On Wednesday, 23 August 2017 at 13:12:04 UTC, Mike Parker wrote:
> To coincide with the improvements to -betterC in the upcoming DMD 2.076, Walter has published a new article on the D blog about what it is and why to use it. A fun read. And I'm personally happy to see the love this feature is getting. I have a project I'd like to use it with if I can ever make the time for it!
>
> The blog:
>
> https://dlang.org/blog/2017/08/23/d-as-a-better-c/
>
> Reddit:
> https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/

Questions regarding c++ classes in betterC mode. Can the c++ class destructor be called by the destroy function or do I have to call it explicitly like p-<~class()?

Alex
August 24, 2017
On Wed, Aug 23, 2017 at 10:17 AM, Kagamin via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> Not a better C, but intermediate D has small footprint for me too.

What is "intermediate D"?

-Parke

> 7.5kb totext.exe (encodes stdin to base64 and writes to stdout) - wrote it
> to put images in xml for opensearch descriptions.
> 12.5kb retab.exe (retabifies source code with various features)
> 5.5kb keepower.exe (manages screen saver and power settings because of
> obnoxious domain policy)
> 14.5kb fsum.exe (computes various hash sums of a file)
>
> Additional features: string switch, array cast. Also how assert failure works in C? Mine shows a nice formatted message.
August 24, 2017
On 8/24/2017 11:56 AM, Walter Bright wrote:
>> I find -betterC to be somewhat of a copout for avoiding the hard work of improving D's implementation.
> 
> On the contrary, I view it as providing motivation for dealing with those issues. The PR above is stalled for lack of motivation.

-betterC also brings into sharp focus exactly what the issues are.
August 24, 2017
On Thursday, 24 August 2017 at 18:56:25 UTC, Walter Bright wrote:
>
> There is a PR to make it only on demand,
>
>   https://github.com/dlang/dmd/pull/6561
>
> but it is mired in problems that are not in the D test suite and for which no test cases exist.

C++ compilers also have a switch, like -fno-rtti, for de-activating RTTI. BetterC seems like a combination of several pieces of underlying functionality. There is not yet any ability to have any kind of granularity. For instance,
-betterC=[flag]
where [flag] might be something like "off-dassert" which calls the C assert function instead of the D one.