Is getting a whole lot better:

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

You can now build D executables that do not link in anything from Phobos - only from the standard C library.

On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote:
> Is getting a whole lot better:
>
> https://github.com/dlang/dmd/pull/6918
>
> You can now build D executables that do not link in anything from Phobos - only from the standard C library.

To be fair, this is not new, just more convenient :)

http://forum.dlang.org/post/qcbicxrtmjmwiljsyhdf@forum.dlang.org

On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote:
> Is getting a whole lot better:
>
> https://github.com/dlang/dmd/pull/6918
>
> You can now build D executables that do not link in anything from Phobos - only from the standard C library.

Thanks!

On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote:
> Is getting a whole lot better:

It looks to me that this patch does two things:

1) -betterC now implies -defaultlib=
2) -betterC omits the call to _d_dso_registry


And I see a previous patch is also in there that uses C's `assert` instead of D's with -betterC. (frankly, I like the C one better anyway!)


So these are baby steps toward making -betterC actually useful, but just baby steps.

To all, I'd hold off on posting this to external forums until more of the open bugzilla issues are changed (I saw Walter tagging them earlier today, so I know they are on his radar).

Importantly, at a minimum, structs need to just work with `-betterC` before I'd announce it to the outside world. Once that happens, then I think we have something to talk about.... so getting closer, but not quite to the point where I'm excited yet.

On 6/19/2017 6:53 PM, Vladimir Panteleev wrote:
> To be fair, this is not new, just more convenient :)
> 
> http://forum.dlang.org/post/qcbicxrtmjmwiljsyhdf@forum.dlang.org

Convenience is everything!

On 6/19/2017 7:55 PM, Adam D. Ruppe wrote:
> To all, I'd hold off on posting this to external forums until more of the open bugzilla issues are changed (I saw Walter tagging them earlier today, so I know they are on his radar).

https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=betterc&keywords_type=allwords&list_id=215478&query_format=advanced


> Importantly, at a minimum, structs need to just work with `-betterC` before I'd announce it to the outside world.

Which issue is that?

On Tuesday, 20 June 2017 at 03:54:13 UTC, Walter Bright wrote:
> Which issue is that?

There isn't a specific bugzilla entry, but the very first one on your list mentions it:
https://issues.dlang.org/show_bug.cgi?id=11881

and it is caused by typeinfo:
https://issues.dlang.org/show_bug.cgi?id=14758


I wrote about it in more depth in TWID:
http://arsdnet.net/this-week-in-d/2016-oct-09.html

We're about half way to my minimum win condition described there.

On 6/19/2017 9:08 PM, Adam D. Ruppe wrote:
> On Tuesday, 20 June 2017 at 03:54:13 UTC, Walter Bright wrote:
>> Which issue is that?
> 
> There isn't a specific bugzilla entry, but the very first one on your list mentions it:
> https://issues.dlang.org/show_bug.cgi?id=11881

There's a lot mentioned there. Can you be more specific? 11881 is all over the map and should be closed, with any remaining problems posted as individual actionable bugzilla issues. Can you do this?

> and it is caused by typeinfo:
> https://issues.dlang.org/show_bug.cgi?id=14758
> 
> 
> I wrote about it in more depth in TWID:
> http://arsdnet.net/this-week-in-d/2016-oct-09.html

Please file bugzilla issues for remaining problems.

On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote:
> Is getting a whole lot better:
>
> https://github.com/dlang/dmd/pull/6918
>
> You can now build D executables that do not link in anything from Phobos - only from the standard C library.

While it's encouraging to see some attation given to this feature, I think the fundamental premise motivating -betterC is misguided.

Rather than requiring a switch that bluntly disables certain features of the language, the compiler and/or linker should simply not require implementations that aren't explicitly or implicitly used.  For example, if one is not doing any dynamic casting or other runtime inspection, the toolchain should not throw any errors about a missing TypeInfo implementation, and the toolchain certainly shouldn't add automatically generated TypeInfo implementations to the binary that have no hope of every being referenced or executed.

As I understand it, this requires some cooperation between the compiler and the linker.  For example, the compiler may not be able to determine whether or not a certain language feature or implementation is required, so it will include a link to it anyway in the intermediate object file, but the linker will be able to see that there is no possible logic path to that code in the final binary, and can strip it out rather than generate an unresolved symbol error.  GCC's -ffunction-sections/-fdata-sections and ld's --gc-sections do this quite well, though better implementations may also be possible with LTO features.

I think all features of D have their place even in bare metal and resource constrained microcontroller programming.  For example, despite the disdain from others, I use C++ exceptions in much of my microcontroller programming because it makes the "happy path" a little bit faster at the expense of making the "unhappy path" (whose performance doesn't matter) much slower.  It also makes my code much easier to reason about, and escape out of when something goes wrong.

Similarly, I can also see TypeInfo and ModuleInfo being useful for certain applications.  For example, ModuleInfo and module constructors may be a good way to initialize peripherals before calling main().  However, the toolchain shouldn't require TypeInfo and ModuleInfo to always be there just to get a build when they have no chance of ever being referenced or executed in the final binary.

If one wanted to avoid certain druntime dependencies, they should be able to simply avoid those features of D in their source code for which there is no runtime implementation (e.g. exceptions, classes, AAs, etc...) or provide their own implementation embedded in their code that overrides the druntime implementation.

On a system with a full desktop-like operating system it would be convenient to automatically link in druntime and maybe Phobos, but that should be done on a platform-by-platform basis in either a dmd.conf, linker script, or some other similar configuration file that is distributed with the toolchain's package.

I think it would be better to refactor the DMD and druntime implementations to reduce their coupling and improve their cooperation with the linker and LTO features.  In doing so, a -betterC switch would be rendered redundant and ultimately needless.

Mike

On 6/19/2017 11:28 PM, Mike wrote:
> As I understand it, this requires some cooperation between the compiler and the linker.

We don't control the linker. We could do a lot if we did, but we don't.