On 19/02/2018 21:17, Andre Pany wrote:
> On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
>> Glad to announce the first beta for the 2.079.0 release, ♥ to the 77 contributors for this release.
>>
>> [...]
> 
> This release is fantastic!
> 
> In the change log information about lld linker is missing. Maybe you can add
> some info how to use it instead of link.exe (the OMF one).
> 
> Kind regards
> André

LLD does not replace the OMF linker, but the MS linker for COFF.

The Windows installer also comes with platform libraries built from the mingw definitions and a wrapper library for the VC distributable C runtime libraries. This allows using dmd with -m64 and -m32mscoff without having to install Visual Studio, the VC build tools or the Windows SDK.

I'll add a PR for the changelog...

On Monday, 19 February 2018 at 18:50:47 UTC, Dukc wrote:

> Huh? Did I understand right? Just add an empty object.d into your project and --BetterC is now basically needless, plus the executable is most likely even smaller?

Kindof, but not exactly.  The -betterC switch still adds some nuance such as...

> assert failures are directed to the C runtime library
https://dlang.org/spec/betterc.html

... just to name one.

Though, with 2.079, you should be much less constrained in your no-/partial- runtime implementation.

For example, I'm exploring a minimal runtime implementation for using D on bare-metal microcontrollers (https://github.com/JinShil/stm32f42_discovery_demo)  The device tree (i.e. bus/peripherals/registers/bitfields) is statically known at compile-time.  I use this pattern to model the device tree...

final abstract class RCC : Peripheral!(AHB1, 0x3800)
{
    final abstract class CR : Register!(0x00, Access.Byte_HalfWord_Word)
    {
        alias PLLSAIRDY = Bit!(29, Mutability.r);
        alias PLLISAION = Bit!(28, Mutability.rw);
    }
}
https://github.com/JinShil/stm32f42_discovery_demo/blob/93f2c53578a18e8ce8e6a3985db14f361590f07f/source/stm32f42/rcc.d#L24

That would be impossible with -betterC, because -betterC doesn't support classes.

I suspect others will find more compelling use cases.

With 2.079 it may also be possible to implement certain features of D that are disabled in -betterC by providing custom implementations of runtime hooks (https://wiki.dlang.org/Runtime_Hooks) or other features in the runtime.

I'm of the opinion, however, that with the right changes to the compiler-runtime coupling, as demonstrated in 2.079, a better C can be achieved without the -betterC compiler switch.  There's still more work to be done, though, and the -betterC compiler switch will still have its uses.  It should be noted, however, that it was the work done on -betterC that made the changes in 2.079 possible.

Mike

On Monday, 19 February 2018 at 21:50:02 UTC, Rainer Schuetze wrote:
>
>
> On 19/02/2018 21:17, Andre Pany wrote:
>> On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
>>> Glad to announce the first beta for the 2.079.0 release, ♥ to the 77 contributors for this release.
>>>
>>> [...]
>> 
>> This release is fantastic!
>> 
>> In the change log information about lld linker is missing. Maybe you can add
>> some info how to use it instead of link.exe (the OMF one).
>> 
>> Kind regards
>> André
>
> LLD does not replace the OMF linker, but the MS linker for COFF.
>
> The Windows installer also comes with platform libraries built

Just one step left to get an unified debug experience then: dward2 debug info for windows COFF objects.

Is that right ?

On 20/02/2018 01:58, Basile B. wrote:
> On Monday, 19 February 2018 at 21:50:02 UTC, Rainer Schuetze wrote:
>>
>>
>> On 19/02/2018 21:17, Andre Pany wrote:
>>> On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
>>>> Glad to announce the first beta for the 2.079.0 release, ♥ to the 77 contributors for this release.
>>>>
>>>> [...]
>>>
>>> This release is fantastic!
>>>
>>> In the change log information about lld linker is missing. Maybe you can add
>>> some info how to use it instead of link.exe (the OMF one).
>>>
>>> Kind regards
>>> André
>>
>> LLD does not replace the OMF linker, but the MS linker for COFF.
>>
>> The Windows installer also comes with platform libraries built
> 
> Just one step left to get an unified debug experience then: dward2 debug info for windows COFF objects.
> 
> Is that right ?

I don't think that is planned in the near future.

AFAICT DWARF debug support in dmd is not better than COFF (GDC might have an edge here), but using gdb instead of the VS debugger (or any other debugger suporting standard debug info) on Windows is pretty uncommon.

On Monday, 19 February 2018 at 18:50:47 UTC, Dukc wrote:
> Huh? Did I understand right? Just add an empty object.d into your project and --BetterC is now basically needless, plus the executable is most likely even smaller?
>
> And more functions to std.range, my favorite module, yes!

FWIW I used ldc with minimal runtime since 2013 or so, 2.079 is if you want to use dmd and classes.

On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
> 17. Allow multiple selective imports from different modules in a single import statement
>
> I have a bad feeling that that one is going to be a source of a raft of bugs for years to come.

No need to use it if you don't like it. It's particularly useful for small examples, localized imports and hacking.
It's mainly a generalisation of the existing possibility to mix module imports and one selective import at the end.
If you prefer java-like 50 lines import manifests, then by all means keep using those.
How would that feature cause bugs though?

On Monday, 19 February 2018 at 23:37:49 UTC, Mike Franklin wrote:
> On Monday, 19 February 2018 at 18:50:47 UTC, Dukc wrote:
>> ...
>
>
> Mike


@"16.": https://dlang.org/changelog/2.079.0.html#minimal_runtime

So, now someone could "easily" write his own memory managment for allocations who would be usually done by the default GC - e.g. classes?

On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak wrote:
> If you prefer java-like 50 lines import manifests, then by all means keep using those.

Imports can be written on one line.

import std.stdio; import std.range;

It only needs one more word.

On Tuesday, 20 February 2018 at 08:46:02 UTC, meppl wrote:
> So, now someone could "easily" write his own memory managment for allocations who would be usually done by the default GC - e.g. classes?

That isn't connected to object.d, but you can allocates classes where you want since ages.
Just write a wrapper around `__traits(classInstanzeSize, ...)` or use http://code.dlang.org/packages/automem.

On Monday, 19 February 2018 at 15:45:30 UTC, bachmeier wrote:
> This looks good, but I'm not sure the many new features go well with the "2 month release" thing. I hope there are plans for a longer than usual testing period. Your announcement reads to me like it's going to be a regression bug release.

Well, we already run a lot of automated tests and the best way to help us avoiding regressions is by properly testing the beta against your code.
Betas start on the 15th of every even month, releases are done 2 weeks later on the 1st of every odd month.