August 23, 2017
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.

- Jonathan M Davis

August 23, 2017
On Wednesday, 23 August 2017 at 17:39:00 UTC, Walter Bright wrote:
> On 8/23/2017 10:26 AM, jmh530 wrote:
>> Am I correct that betterC requires main to be extern(C) and must act like a C main (i.e. no void return)?
>
> Yes.

This might be added to
http://dlang.org/dmd-windows.html#switch-betterC
or
http://dlang.org/spec/betterc.html

>
>> Is that something that can be changed in the future?
>
> Yes, but I don't see a need for it.

Fair enough. A version statement could handle it

version(BetterC)
{
    extern(C) int main()
    {
        callRealMain();
    }
}
else
{
    void main()
    {
        callRealMain();
    }
}

August 23, 2017
On Wednesday, 23 August 2017 at 16:17:57 UTC, SrMordred wrote:
> No structs in -betterC ???

I haven't tried the latest iteration of betterC yet, but the longstanding problem is that the compiler generates TypeInfo instances for structs, and TypeInfos are classes, which inherit from Object, which are implemented in the D runtime.  If you're using the current release of D, the workarounds are to include an implementation of Object so that classes work, or hack out the TypeInfo at link time.
August 23, 2017
On Wednesday, 23 August 2017 at 17:43:27 UTC, Steven Schveighoffer wrote:
> On 8/23/17 11:59 AM, Walter Bright wrote:
>> On 8/23/2017 7:37 AM, Steven Schveighoffer wrote:
>>> How do dynamic closures work without the GC?
>> 
>> They don't allocate the closure on the GC heap. (Or do I have static/dynamic closures backwards?)
>
> I thought "closure" means allocating the stack onto the heap so you can return the delegate with its context intact.
>
> From https://en.wikipedia.org/wiki/Closure_(computer_programming) :
>
> "A language implementation cannot easily support full closures if its run-time memory model allocates all automatic variables on a linear stack. In such languages, a function's automatic local variables are deallocated when the function returns. However, a closure requires that the free variables it references survive the enclosing function's execution. Therefore, those variables must be allocated so that they persist until no longer needed, typically via heap allocation, rather than on the stack, and their lifetime must be managed so they survive until all closures referencing them have are no longer in use."

Right, so if we wanted to support closures in betterC (we don't now, as my earlier example shows), they'd need a separate lifetime management implementation.
The two straightforward ones are either disable copying of closures in betterC (only moving them), so a single ownership model of their heap allocated context pointer is possible (deallocating the memory once the closure is destroyed), or make them reference counted.
The first has the disadvantage that you can't have two closures point to the same heap context (though to be honest, I haven't seen a codebase so far that actually uses that), but it should be trivial to implement. The RC variant is more complex (it would require an analysis if reference cycles can occur), but I think this might be one of the cases where RC is the right solution (and we might even consider using RC in normal D as well, if it works sanely).
August 23, 2017
On Wednesday, 23 August 2017 at 17:44:31 UTC, Jonathan M Davis wrote:
> I confess that I tend to think of betterC as a waste of time.

The overwhelming majority of programmers don't need betterC.  At all.  But today we live in a world where practically everything just builds on top of C, and we keep seeing how that goes wrong.  I think Rust and betterC D are the best candidates we've got for replacing C everywhere C is used.
August 24, 2017
On Wednesday, 23 August 2017 at 17:44:31 UTC, Jonathan M Davis 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.

I'm somewhat in agreement here.  I wouldn't call it a "waste of time", but I would prefer refactoring D's implementation to make using full-featured D from C/C++ less of a pain.  I fear, however, that -betterC will be the favored excuse for not pursuing or prioritizing such improvements.

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.  I find -betterC to be somewhat of a copout for avoiding the hard work of improving D's implementation.

Mike
August 23, 2017
On Thu, Aug 24, 2017 at 12:35:22AM +0000, Michael V. Franklin via Digitalmars-d-announce 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.  I find -betterC to be somewhat of a copout for avoiding the hard work of improving D's implementation.
[...]

One thing that would help is if things like TypeInfo, ModuleInfo, etc., are only emitted on-demand, or if they are stored as weak symbols in the object file so that the linker can just omit them if they are never referenced.

Ideally, the GC would also be on-demand, but it's currently too tightly integrated with druntime for this to be possible. At least, it would take a huge amount of effort to make it work.  Similarly, thread-related stuff might be difficult to make optional, since the D startup code is dependent on it.

Other smaller things in druntime like string switches, array comparison functions, etc., could possibly also be optionally included, but then you'll need to link (parts of) druntime. It will be more troublesome, but within the realm of possibility, I think.

I, for one, would be happier if D's features are more pay-as-you-go so that simpler programs don't have to pull in a whole bunch of executable bloat that's not actually going to be used.


T

-- 
Let's eat some disquits while we format the biskettes.
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/

Thanks for this feature! Looking forward to see its future  --Ilya
August 24, 2017
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.
August 24, 2017
On Wednesday, 23 August 2017 at 22:45:27 UTC, sarn wrote:
> I haven't tried the latest iteration of betterC yet, but the longstanding problem is that the compiler generates TypeInfo instances for structs

LDC doesn't generate TypeInfo for structs until it's required for some features like array comparison.