On Tuesday, 7 June 2016 at 17:38:01 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 7 June 2016 at 17:04:19 UTC, jmh530 wrote:
>> How about no headers or macros?
>
> Textual include files are annoying and C++ needs more symbolic modules, but not having the ability to use namespaces is annoying too and D's take on name resolution can break code.

Maybe I should explain the namespace part, as what I am referring to is a relatively new feature in C++ called "inline namespaces".

I basically do this in different include files:


namespace mylib {
    inline namespace common {
        // stuff I want to use without prefix or with ::mylib::*
    }
    // stuff I want to use with prefix ::mylib::*
}


When I include various parts of mylib I simply write

"use namespace ::mylib::common;"

Then all symbols in ::mylib::common is accessible without prefixing it, but I can choose to use explicit prefixing ::mylib::... whenever I want to anyway.

Handy for not polluting the namespace, but also getting easy access to things often used in conditional like "is_empty(x)".

Not sure if other people do this, but I like it.

On Tuesday, 7 June 2016 at 17:09:38 UTC, Dave wrote:
> Incorrect. Pike, on a panel with D's Andrei, even said that when they labeled Go a systems programming language it was kind of taken in a way they didn't mean. It's more of a server programming language. I don't think Pike would agree that Go would be the best choice for an OS. I'm sure you can create one, and I'm sure he'd agree with this, but I doubt he'd personally reach for it.

There was actually a person from an academic OS research team that wrote about adopting Go (probably changing it) for an experimental OS implementation. Someone on the Go team thought it was a good idea and also that they could do it using garbage collection... so well... I am not sure if they are sober about what Go is suitable for... ;-)

(but yes, they are no longer developing it as a system level language)

On 6/6/2016 9:31 AM, Shachar Shemesh wrote:
> With the *possible* exception of C#, none of those are systems
> programming languages. D presents itself as one.
>
> Shachar

I think that is true.

I understand that some disciplines might need to avoid a GC for whatever reason, like games or small embedded systems.

But the thing that always gets me about GC is not performance. It's that garbage collection always lumps all resources together with memory. I understand that there have been countless long discussions about GC. But my eyes glaze over because the discussion is usually about performance. Coming from C++ I like to use RAII. I like to depend on deterministic destruction of resources. I don't care about memory or when it's released (depending on the type of application) but I do care when other types of resources are released. If I'm wrong to be thinking this way I'm happy to be convinced otherwise.

I know the library has Unique which is in std.typcons. But I thought I also read once that there are certain cases where it doesn't always work correctly. Maybe I'm mistaken; I'm not clear on that. As a developer coming from C++, okay, I've bought into the idea that D is a better C++. The first thing I want to know is, "How do I accomplish all the things in D that I normally do in C++?" For the case of deterministic destruction it might take someone a while to figure that out. (Not scope guards; they don't handle lifetimes longer than functions.)

On 6/7/2016 10:44 AM, Timon Gehr wrote:
> How do you know that some random @safe PR pulled into your project does not
> corrupt memory?

@trusted and @system are designed to be greppable, i.e. you can look for them without needing a static analysis tool.

On Tuesday, 7 June 2016 at 18:15:28 UTC, Walter Bright wrote:
> @trusted and @system are designed to be greppable, i.e. you can look for them without needing a static analysis tool.

But you can't grep for @system because 99% of the time it's implicit. This problem becomes harder to find when using templates for everything, which I do.

On 6/7/2016 11:19 AM, Jack Stouffer wrote:
> On Tuesday, 7 June 2016 at 18:15:28 UTC, Walter Bright wrote:
>> @trusted and @system are designed to be greppable, i.e. you can look for them
>> without needing a static analysis tool.
>
> But you can't grep for @system because 99% of the time it's implicit. This
> problem becomes harder to find when using templates for everything, which I do.

Add:

   @safe:

at the top of your D module and you'll find the @system code. The D compiler is the static analysis tool. It's true that @safe should have been the default, but too much code would break if that were changed. Adding one line to the top of a module is very doable for those that are desirous of adding the safety checks.

You can also add:

   @nogc:

at the top, too. It isn't necessary to tediously annotate every function.

On Tuesday, 7 June 2016 at 18:24:33 UTC, Walter Bright wrote:
> You can also add:
>
>    @nogc:
>
> at the top, too. It isn't necessary to tediously annotate every function.

@nogc:

struct Foo {
        int* a() { return new int; }
}

On 07.06.2016 20:15, Walter Bright wrote:
> On 6/7/2016 10:44 AM, Timon Gehr wrote:
>> How do you know that some random @safe PR pulled into your project
>> does not
>> corrupt memory?
>
> @trusted and @system are designed to be greppable,

$ grep -r "@trusted" *
$ grep -r "@system" *

> i.e. you can look for
> them without needing a static analysis tool.

mixin("@tru"~"sted void foo(){ ... }");

Anyway, this is not actually the issue. One can hack the compiler such that it reports locations of @trusted functions easily.

I still don't know the code is memory safe if main is @safe and there are no @trusted functions in the code. The @safe subset should be specified and implemented by inclusion, such that it is obvious that it does the right thing. I don't know what's 'unspecific' about this. Closing holes one-by-one is not the right approach here. You don't know when you are done and might never be.

On Tuesday, 7 June 2016 at 18:24:33 UTC, Walter Bright wrote:
> On 6/7/2016 11:19 AM, Jack Stouffer wrote:
>> On Tuesday, 7 June 2016 at 18:15:28 UTC, Walter Bright wrote:
>>> [...]
>>
>> But you can't grep for @system because 99% of the time it's implicit. This
>> problem becomes harder to find when using templates for everything, which I do.
>
> Add:
>
>    @safe:
>
> at the top of your D module and you'll find the @system code. The D compiler is the static analysis tool. It's true that @safe should have been the default, but too much code would break if that were changed. Adding one line to the top of a module is very doable for those that are desirous of adding the safety checks.
>
> You can also add:
>
>    @nogc:
>
> at the top, too. It isn't necessary to tediously annotate every function.

Seems fair. But perhaps phobos should also follow this standard? Which might be why people get the mindset that they have to annotate everything...

On 07.06.2016 17:11, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Jun 07, 2016 at 02:31:43PM +0000, Steven Schveighoffer via Digitalmars-d wrote:
>> On Tuesday, 7 June 2016 at 13:47:39 UTC, H. S. Teoh wrote:
>>> .
>>>
>>> I can't seem to find an issue I filed some years ago about @safe
>>> needing to be whitelist-based rather than blacklist-based. Did it
>>> get closed while I wasn't looking?
>>
>>
>> This one?
>>
>> http://forum.dlang.org/post/mailman.2912.1465288884.26339.digitalmars-d-bugs@puremagic.com
> [...]
>
> Oh yes, that's the one.
>
>
> T
>

You didn't find it because it was closed by Walter for no good reason about 10 hours ago.