On Friday, 7 August 2020 at 13:24:36 UTC, Andrei Alexandrescu wrote:
> On 7/7/20 8:04 AM, Steven Schveighoffer wrote:
>> On 7/7/20 7:13 AM, 9il wrote:
>>> On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote:
>>>> On 7/5/2020 5:46 AM, Joseph Rushton Wakeling wrote:
>>>>> On Sunday, 5 July 2020 at 11:07:55 UTC, 9il wrote:
>>>>>> There is no risk for DMD and DFL to depend on a Mir's Boost licensed library. If something happens with Mir or Mir change the license, DFL will be able to fork the required code at any point in the Boost licensed part of git history.
>>>>>
>>>>> Can't speak for Walter or the D foundation here, but I'm not sure the concern is really about licensing.  It's about putting in place a required dependency on code where maintenance decisions are outside the hands of the D Foundation.
>>>>
>>>> That's right, it's not about the licensing. It's that the DLF should control the code it distributes.
>>>>
>>>> Businesses will not want to commit to a balkanized project.
>>>>
>>>> The proposal is for Mir to become a central required component of DMD and Phobos. This means it needs to become part of the D Language Foundation.
>>>
>>> These don't serve my business needs. DLF doesn't serve my business needs. DLF blocks the initiatives my business needs. For the current state of things being a part of DLF codebase for Mir is nonsense.
>> 
>> Guys, this is all open source, all licensed identically. There are ways to solve this. Practically speaking, just because DMD depends on Mir, doesn't mean that Mir has control over how the dependency works. DMD can depend on a specific version of Mir, upgraded when reasonable (i.e. it should take a PR change to DMD for upgrading which code exactly is depended on) and if something changes in the future, you can fork it, or move back to using libc. This way, the code is only maintained in one place unless something catastrophic happens.
>> 
>> In this sense, the DLF *does* control which code is used, as well as if it were in the DMD repository itself.
>> 
>> We have a boost license for a reason.
>
> FWIW it would be wisest to simply copy the code from Mir into druntime now with due credit. It's a minimally committal decision than can be easily revisited later. It is legal, appropriate, and there's no shame to it any more than it is for other projects to fork (parts of) dmd, druntime, or phobos.

What's the purpose of that? If someone needs Mir, they can just add it as a dependency in dub. This will just be adding more bloat to drubtime. The development surrounding D seems to have a stigma of using external dependencies even when there is significant benefit. I find it odd that you bring up that there's no shame to copy and paste. It seems the only reason there simply wouldn't be a link to a dependency is because of stigma. There's no shame relying on another project and you don't have to copy and paste it. Optlink, DMC, DMC's club, etc. Its gotten better than it was, but there's no reason to even use any of those anymore, supporting them is just a waste of time. As would maintaining a copy pasta of Mir would be.

On Saturday, 8 August 2020 at 18:16:30 UTC, Avrina wrote:
 there's no shame to it any more than it is
> What's the purpose of that? If someone needs Mir, they can just add it as a dependency in dub. This will just be adding more bloat to drubtime. The development surrounding D seems to have a stigma of using external dependencies even when there is significant benefit. I find it odd that you bring up that there's no shame to copy and paste. It seems the only reason there simply wouldn't be a link to a dependency is because of stigma. There's no shame relying on another project and you don't have to copy and paste it. Optlink, DMC, DMC's club, etc. Its gotten better than it was, but there's no reason to even use any of those anymore, supporting them is just a waste of time. As would maintaining a copy pasta of Mir would be.

It's not about shame. It's about a guarantee of control, that the code and behaviour doesn't change unless you want it to, and about minimizing complexity for users trying to build the project from scratch. Phobos' zlib dependency is copy-pasted in the codebase for similar reasons.

On Saturday, 8 August 2020 at 18:16:30 UTC, Avrina wrote:
> On Friday, 7 August 2020 at 13:24:36 UTC, Andrei Alexandrescu wrote:
>> On 7/7/20 8:04 AM, Steven Schveighoffer wrote:
>>> On 7/7/20 7:13 AM, 9il wrote:
>>>> On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote:
>>>>> On 7/5/2020 5:46 AM, Joseph Rushton Wakeling wrote:
>>>>>> On Sunday, 5 July 2020 at 11:07:55 UTC, 9il wrote:
>>>>>>>
>>
>> FWIW it would be wisest to simply copy the code from Mir into druntime now with due credit. It's a minimally committal decision than can be easily revisited later. It is legal, appropriate, and there's no shame to it any more than it is for other projects to fork (parts of) dmd, druntime, or phobos.
>
> What's the purpose of that? If someone needs Mir, they can just add it as a dependency in dub. This will just be adding more bloat to drubtime. The development surrounding D seems to have a stigma of using external dependencies even when there is significant benefit. I find it odd that you bring up that there's no shame to copy and paste. It seems the only reason there simply wouldn't be a link to a dependency is because of stigma. There's no shame relying on another project and you don't have to copy and paste it. Optlink, DMC, DMC's club, etc. Its gotten better than it was, but there's no reason to even use any of those anymore, supporting them is just a waste of time. As would maintaining a copy pasta of Mir would be.

Per the original post in this thread, the current compiler doesn't convert decimal floating point literals to binary form correctly in all normal cases.  Assuming people actually want to be correct/consistent to the last bit wherever possible, that should change.

Additionally, the default library conversions should match those of the compiler. They should also be correct/consistent.

This could be accomplished by introducing Mir dependencies in a few places but I think fully accredited copying is a better way to go.  There is more to maintain, true, but accurate conversion is fundamental in nature.  We're not talking about some high level library here.  Hard to get right? Apparently.  Esoteric?  No.

As to timing, if the subnormal update Ilya mentioned is very close it would make sense to wait for that version.

Side note: the truly persnickety/paranoid might favor hex floating point literals but those are pretty hard on human readers.  At least the conversion implementations should not require heroics.

On Saturday, 8 August 2020 at 22:13:57 UTC, Bruce Carneal wrote:
> 
>
> Per the original post in this thread, the current compiler doesn't convert decimal floating point literals to binary form correctly in all normal cases.  Assuming people actually want to be correct/consistent to the last bit wherever possible, that should change.
>
> Additionally, the default library conversions should match those of the compiler. They should also be correct/consistent.
>
> This could be accomplished by introducing Mir dependencies in a few places but I think fully accredited copying is a better way to go.  There is more to maintain, true, but accurate conversion is fundamental in nature.  We're not talking about some high level library here.  Hard to get right? Apparently.  Esoteric?  No.
>
> As to timing, if the subnormal update Ilya mentioned is very close it would make sense to wait for that version.
>
> Side note: the truly persnickety/paranoid might favor hex floating point literals but those are pretty hard on human readers.  At least the conversion implementations should not require heroics.

OTOH, this is pretty small potatoes when compared to other CTFE floating point discrepancies (no control of precision, all to 'real' IIUC).  Maybe the best that can be done is to align the library with better practice.