On Friday, 24 August 2018 at 04:50:34 UTC, Mike Franklin wrote:
> On Friday, 24 August 2018 at 04:12:42 UTC, Jonathan M Davis wrote:
>
>
> It's not a problem for Phobos to depend on the C standard library.  My goals have to do with making D, the language, freestanding (a.k.a nimble-D).

If the poster feature for D in the upcoming years is memory safety then how can Walter seriously consider continued dependency on libc?

On Friday, August 24, 2018 1:31:21 AM MDT Shachar Shemesh via Digitalmars-d wrote:
> > Yeah. We probably should have required that destructors be nothrow and force destructor failures to be treated as Errors.
>
> I'm sorry, but I'm not following your logic.
>
> If you're willing to have an error raised by a destructor abort the whole program, isn't the C++ solution preferable (abort the program only on double errors, which hardly ever happens)?

The C++ code bases that I've worked on have typically marked destructors with throw() or noexcept, which effectively kills your program whenever an exception is thrown for a destructor, and I'm not sure if I've ever seen it be triggered. It's just not a typical bug in my experience. Either way, since I would consider it a serious bug for an exception to be thrown from a destructor, if it happens, I'd rather have the program just die so that the bug can be noticed and fixed.

- Jonathan M Davis

On Friday, August 24, 2018 2:46:06 AM MDT Dave Jones via Digitalmars-d wrote:
> On Friday, 24 August 2018 at 04:50:34 UTC, Mike Franklin wrote:
> > On Friday, 24 August 2018 at 04:12:42 UTC, Jonathan M Davis wrote:
> >
> >
> > It's not a problem for Phobos to depend on the C standard library.  My goals have to do with making D, the language, freestanding (a.k.a nimble-D).
>
> If the poster feature for D in the upcoming years is memory safety then how can Walter seriously consider continued dependency on libc?

For any kind of normal operating system, you _have_ to use libc. It's part of the OS. Some pieces could be done without it, but on the whole, you use libc if you want to talk to the OS. That's just life. The only exceptions I'm aware of to that are embedded devices, and my understanding is that if anything, such devices are more and more likely to run a fullblown OS, making it that much less likely that you'd ever do anything without libc.

Sure, we don't need to call C functions like strcmp, but if you want to do things like I/O, you have to use the OS' API, and that's libc. And yes, that means that we depend on code that's not vetted via @safe, but at this point, the major OSes are written in C, and they present a C API. So, accessing that functionality means depending on the OS devs to have gotten it right, much as it would be nice if it were verified with something like @safe. The same is going to happen with plenty of existing libraries that are almost certainly not going to have replacements in D (e.g. postgres, ffmpeg, etc). We're never going to completely escape the @safety issues introduced by C. Ultimately, the best that we can do is make sure that the actual D code is @safe as long as any libraries it uses are @safe.

- Jonathan M Davis

On 8/23/2018 7:33 PM, Jonathan M Davis wrote:
> Wow. I'm surprised by this. I definitely agree with David on this one.
> Without being able to throw from a constructor, you can't really have it
> fail, and there are times when it needs to be able to fail. Not being able
> to have throwing constructors basically means having to do two-part
> initialization which I would have thought was almost universally considered
> bad.

Not really. You can use a factory function which can do it for you.


> I expect that you'd have a riot on your hands though if you actually tried
> to push for getting rid of throwing constructors.

Maybe not. C++11 tries hard to discourage their use, and we know how hard they try to not disrupt existing code.

I'd be favorably disposed towards a DIP getting rid of them.

On 8/24/2018 12:31 AM, Shachar Shemesh wrote:
> If you're willing to have an error raised by a destructor abort the whole program, isn't the C++ solution preferable (abort the program only on double errors, which hardly ever happens)?

C++ has changed:

https://akrzemi1.wordpress.com/2013/08/20/noexcept-destructors/

On 8/24/2018 1:45 AM, Trass3r wrote:
> Are you referring to http://wg21.link/P0709 ?

Yes. (please don't use link shorteners, they tend to go poof)

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r1.pdf

On 8/23/2018 5:02 PM, Nicholas Wilson wrote:
> am currently up against a ~thousand headed hydra~ thousand line function .

Good times :-)

On Friday, 24 August 2018 at 01:50:53 UTC, Jon Degenhardt wrote:
>
> quality, consistency, completeness

My point is that it's more important to have useful, easy to change, messy libraries.

If you restrict yourself to whatever is in Phobos then the burden on core developers is only ever increasing.

On Friday, 24 August 2018 at 09:58:13 UTC, Walter Bright wrote:
> On 8/23/2018 5:02 PM, Nicholas Wilson wrote:
>> am currently up against a ~thousand headed hydra~ thousand line function .
>
> Good times :-)

Tell me about it. I'm now wading through its carcass in review. I will split it up but it takes a lot of effort.

On 24/08/18 10:43, FeepingCreature wrote:
> Have you tried to use the excellent Dustmite tool? It's never failed to reduce a bug for me.

Dustmite might be excellent. I wouldn't know. It cannot swallow the Weka code base.

Shachar