January 23, 2023
On Sunday, 22 January 2023 at 21:02:06 UTC, Dom Disc wrote:
> The difference is only
>
> @trusted fn() {
>
> };
>
> vs.
>
> @safe fn() { @trusted {
>
> } };

The second variant looks more verbose and more ugly to me. Also wouldn't it require an extra level of indentation if properly formatted?

> But what we gain is that @save/@system is then a binary attribute and not a cumbersome tri-state anymore. Everything is either safe or not.

Dropping support for the @trusted function attribute even after some deprecation period would be a rather annoying compatibility breaking change. That's a high price for something that is just cosmetics.

Also how do you imagine writing future code that is compatible with both the most recent versions of D compilers and also with GDC 12 (frontend version 2.100)? GDC 12 is included in Ubuntu 22.04 LTS and will be relevant for a very long time.
January 23, 2023
On 1/22/23 22:02, Dom Disc wrote:
> 
>> - Unknown scope of _actual_ `@trusted`, you will have to manually check _`@safe`_ code as well, and a priori you will have no idea how much of it you have to check (this part is terrible).
> 
> Why is this terrible? In worst case you have to check exactly as much code manually as you do today. But in most cases you have to check much less.

It's terrible for the reason I pointed out. It's not modular. A priori _you don't know how much_ code you have to check, you just know that you have to check _some_ `@safe` code, because if you check the `@trusted` lambdas on their own they cannot pass muster.

Officially you only have to check `@trusted` code. However, if you do that, typically all you learn is that the `@trusted` code is bad because it has an unsafe interface...
January 23, 2023

On Monday, 23 January 2023 at 03:19:07 UTC, Siarhei Siamashka wrote:

>

On Sunday, 22 January 2023 at 21:02:06 UTC, Dom Disc wrote:

>

The difference is only

@trusted fn() {

};

vs.

@safe fn() { @trusted {

} };

The second variant looks more verbose and more ugly to me.

That's so because a whole trusted function is an abomination.
Most of the time it should look more like this:

@safe fn()
{
   // lot of safe stuff

   @trusted {
       @assert(/*systemFunc is safe to be used with param1*/);
       @assert(/*systemFunc is safe to be used with param2*/);
       systemFunc(param1, param2);
   }

   // more safe stuff

}

And I like that much more than

@trusted fn()
{
   // lot of safe stuff - why do I need to check that manually?

   // only the two asserts have to be checked manually:
   @assert(/*systemFunc is safe to be used with param1*/);
   @assert(/*systemFunc is safe to be used with param2*/);
   systemFunc(param1, param2);

   // more safe stuff - why do I need to check that manually?

}
> >

But what we gain is that @save/@system is then a binary attribute and not a cumbersome tri-state anymore. Everything is either safe or not.

Dropping support for the @trusted function attribute even after some deprecation period would be a rather annoying compatibility breaking change.

Of course - it should not have been introduced to begin with.
Fixing things very late is always a pain in the ass.

>

That's a high price for something that is just cosmetics.

I don't consider this pure esthetic.
It's also much easier to understand for newcommers.

But ok, I can live with the state we have now. This is more something for D3

January 23, 2023

On Monday, 23 January 2023 at 16:31:01 UTC, Dom DiSc wrote:

>

That's so because a whole trusted function is an abomination.
Most of the time it should look more like this:

@safe fn()
{
   // lot of safe stuff

   @trusted {
       @assert(/*systemFunc is safe to be used with param1*/);
       @assert(/*systemFunc is safe to be used with param2*/);
       systemFunc(param1, param2);
   }

   // more safe stuff

}

Should be:

@safe fn()
{
   // lot of safe stuff

   fghn(param1, param2);

   // more safe stuff
}

@trusted fghn(p1, p2)
{
   assert(...);
   assert(...);
   systemFunc(p1, p2);
}
February 13, 2023

On Tuesday, 6 December 2022 at 23:58:08 UTC, Timon Gehr wrote:

>

On 12/6/22 11:03, Arjan wrote:

>

On Monday, 5 December 2022 at 23:58:58 UTC, Timon Gehr wrote:

>

On 12/5/22 20:57, H. S. Teoh wrote:
Default initialization does not even fix all initialization issues, it just makes them reproducible. Anyway, I think neither default initialization nor uninitialized variables are the right solution, but you kind of have to do it this way given how scoping works in C++ and in D.

Now I'm curious, what, in you opinion, would be best for initialization?

Ideally you just eliminate those cases where a programmer feels like they have to leave a variable uninitialized. The whole concept of "uninitialized variable" does not make a whole lot of sense from the perspective of a safe high-level programming language.

>

How is C++/D scoping limiting in this?

Variables are scoped within the innermost block that they are declared in. Languages like Python that don't have block-local scoping just don't have this particular problem (there's plenty of things to dislike about Python, but this is something it got right I think):

# note there is no x declared here
if cond:
    x = f()
else:
    x = g()
print(x)

A particularly egregious case is the do-while loop:

do{
    int x=4;
    if(condition){
        ...
        x++;
    }
    ...
}while(x<10); // error

Just... why? x)

Maybe this could be addressed by giving do an optional initializer like for. Probably, we’d want this:

do (int x = 4)
{
    if (…) { … x++; }
}
while (x < 10);

But it’s likely an issue for parsing. A more parseable and more general construct would be

do (int x = 4; x++)
{
    if (…) { … x++; }
}
while (x < 10);

Which is effectively a for loop, but the condition x < 10 is checked first after the first iteration and put lexically at the end.

I found myself wishing for a construct like that a few times.

April 28, 2023
On Thursday, 15 December 2022 at 14:36:18 UTC, H. S. Teoh wrote:
> On Thu, Dec 15, 2022 at 09:41:08AM +0000, areYouSureAboutThat via Digitalmars-d wrote:
>> [...]
> [...]
>> [...]
>
> +1, I have always been skeptical about the contemporary trend of using fancy package managers with hairball external dependencies that make your builds dependent on some opaque remote server somewhere out there on the 'Net that you have no control over.  Some time ago somebody also posted another article about how easy it is to conduct MITM attacks on these external package repositories to insert a malicious package / substitute a legitimate package with a malicious version.
>
> [...]

agree
1 2 3 4 5 6 7 8 9 10 11
Next ›   Last »