Re: DIP1028 - Rationale for accepting as is

[H. S. Teoh via Digitalmars-d-announce]

On Fri, May 22, 2020 at 10:50:02PM -0700, Walter Bright via 
Digitalmars-d-announce wrote:
> On 5/22/2020 10:33 AM, rikki cattermole wrote:
> > To me at least, this butchers @safe/trusted/system into a system
> > that is near useless for guarantees for an entire program.
> 
> It never attempted to guarantee safety in code that was never compiled
> with a D compiler. It's impossible to do that. No language does that.

And therefore what we need is a way of indicating verifiability up to
things outside of our control. E.g., some kind of way to express that
the safety of a piece of code is keyed upon some external function or
delegate, thus enabling @safe checks for all code except calls into said
external function/delegate.

This would work out to be practically where we're at now, except that we
don't implicitly pretend external code is @safe where there is no
verification at all.


T

-- 
Designer clothes: how to cover less by paying more.

Re: DIP1028 - Rationale for accepting as is

[Dukc via Digitalmars-d-announce]

On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote:
Just making `@trusted` wrappers over BindBC-nuklear seemed to 
me as inresponsible use of the attribute.


Meant: blindly making the wrappers, without thinking whether 
calling the wrapper would always be `@safe`

Re: DIP 1028--Make @safe the Default--Formal Assessment

[Faux Amis via Digitalmars-d-announce]

On 2020-05-22 03:16, Walter Bright wrote:



The level of negativity in that thread was what caused me to stop 
responding, though I continued reading. Every reply I made produced 10 
responses, an exponential explosion, and yet I was just repeating 
myself. Two sides to every story.


FWIW, I am going to try again with another post here, for those who want 
a convenient summary of the rationale.


Just a suggestion, but sometimes matters are best discussed over 
audio/video. Would having a public teams/zoom/.. meeting be helpful?


I would definitely listen/watch; even if I were muted and could only 
chat maybe.

Re: DIP1028 - Rationale for accepting as is

[Mathias LANG via Digitalmars-d-announce]

On Friday, 22 May 2020 at 18:24:39 UTC, Atila Neves wrote:


Am I saying nothing bad can happen if we implicitly trust 
extern(C) declarations? No. I'm saying we'll be no worse off if 
they're all implicitly @system.


This compiles with no warnings right *now*:

void main() {
import core.stdc.stdlib: free;
free(cast(void*) 42);
free(new int);
free();
}


And this code won't compile at all when you make `@safe` the 
default:


```
void main ()
{
int[] myArray = (cast(int*) malloc(42 * int.sizeof))[0 .. 42];
}
```

So, we changed the default.

Now those people that want to easily prototype something, or 
write applications that extensively use system libraries, will be 
extremely inconvenienced, but we satisfied the people that want 
more `@safe`ty, which we all known and agree is the future.


Except that in that process we also destroyed the meaning of 
`@safe` by shooting a hole into it, for the convenience of the 
people that want to easily prototype something and write 
applications that interact extensively with system libraries, 
because that's what half of the D users do.


Clearly, an improvement.

Re: DIP1028 - Rationale for accepting as is

[Dominikus Dittes Scherkl via Digitalmars-d-announce]

On Friday, 22 May 2020 at 18:24:39 UTC, Atila Neves wrote:

memcpy isn't a good example since it's explicitly @system


Yes, it's a good example. Because if you include any C function, 
you don't know if it uses memcpy internally - except if you have 
the code. And as memcpy is used heavily within C libraries, it's 
not unlikely that your "oh so safe" function is using it too. 
Very bad advice.


It should be simply forbidden to slap @safe at anything with no 
code available, because @save should be reserved for mechanically 
verified parts of code.


Ok, you can slap @trusted on it, and it will compile (the easy 
way), but anyone using it is at least warned. So it's possible to 
check - and if no body is availabe (e.g. an object library) I 
would refrain from trusting it.


But I don't want the compiler to greenwash it for me, no thanks. 
There should be at least someone on the D side to blame, 
destroying his reputation by slapping @trusted at whole modules.

Re: DIP1028 - Rationale for accepting as is

[Paolo Invernizzi via Digitalmars-d-announce]

On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote:

When I look my own code that uses the Nuklear GUI library, 
written in C, it's all `@system`. I have not had the time to 
make `@trusted` wrappers over the BindBC-nuklear API, so I did 
what tends to occur to us as the next best thing: resign and 
make the whole client code `@system`.


I really don't understand, there's no "maybe" memory safety: if 
there's no time to spend for memory safety in a project, why care?


Just making `@trusted` wrappers over BindBC-nuklear seemed to 
me as inresponsible use of the attribute. And reading this 
theard, it would seem like most of you would agree.


I disagree: if you *really* want to use @safe in the rest of the 
codebase, just mark the binding as trusted, raising your hand 
towards reviewers (or everybody is interested in checking the 
memory safety of the project codebase), writing in the comment 
that "you" have decided to spend no time in a proper wrapping, 
and the motivations.


Let the reviewers and the other guys out there just decide what 
to do with your codebase.


But when I think it, what I have accomplised from avoiding that 
antipattern? The only difference is, that if my D code does 
something `@system`, it'll remain under the radar. So I'm worse 
off than had I submitted to the antipattern!


It's not an anti pattern, it clearly show your motivation, that's 
all about @trusted. May also write a big *disclaimer* in the 
README pointing to the pitfalls

Work = Resources * Efficiency

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

Work = Resources * Efficiency

Applicable to IT, CS, and any other form of engineering.

Just putting that out there, FWIW.

Sources:
-

"Efficiency": Merriam-Webster 
:


1: the quality or degree of being efficient ("X is X! Yawn, tell me 
something that means something!")


2.a: efficient operation (ehh? Ehhh!?!?!)

2.b.1: effective operation as measured by a comparison of production 
with cost (as in energy, time, and money): (Ahh, so: efficiency is 
"produced work" vs "resources required to produce that amount of work"!!!)


2.b.2: the ratio of the useful energy delivered by a dynamic system to 
the energy supplied to it: (Ahh, so, once again: "produced work vs 
resources required to produce that amount of work")


3: efficiency apartment: "a small usually furnished apartment with 
minimal kitchen and bath facilities" --- ummm...not relevant...?




"Efficiency": Dictionary.com 

1. the state or quality of being efficient, or able to accomplish 
something with the least waste of time and effort; competency in 
performance.


"Able to accomplish something" (ie, "work") "with the least waste of 
time an effort" (ie, using minimum "resources")


2. accomplishment of or ability to accomplish a job with a minimum 
expenditure of time and effort: The assembly line increased industry's 
efficiency. ("ability to accomplish a job" == "work", "expenditure of 
time and effort" == "resources")


3. the ratio of the work done or energy developed by a machine, engine, 
etc., to the energy supplied to it, usually expressed as a percentage. 
("work done or energy developed by a machine, engine, etc." == "work", 
"the energy supplied to it" == "resources"...ie: "the ratio of ["work"] 
to ["resources"]" == "efficiency")


4. efficiency apartment: "a small apartment consisting typically of a 
combined living room and bedroom area, a bathroom, and a kitchenette." - 
Not relevant.

Re: DIP1028 - Rationale for accepting as is

[Dukc via Digitalmars-d-announce]

On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote:
The more I think of Atila's and Walter's responses, the more 
they are starting to make sense.

[snip]


In fact this former antipattern means that it'd make sense to 
have an inverse of `@trusted` attribute, lets say `@suspect`. It 
would mean that the body of the function is verified just like 
`@safe`, but calling it is allowed only within `@system` or 
`@trusted` code.

Re: DIP1028 - Rationale for accepting as is

[Steven Schveighoffer via Digitalmars-d-announce]

On 5/22/20 8:05 PM, Walter Bright wrote:

On 5/22/2020 10:54 AM, Atila Neves wrote:
BTW, you should fix that invalid attribute, freeing a pointer is 
never @safe unless you can guarantee nobody else has a copy of that 
pointer (and considering it's passed by value, the CALLER still has 
that pointer!)


You're completely right.


@live is intended to fix that!

To get ahead of the curve, annotate pointer parameters with `scope` if 
you don't intend to transfer ownership to the callee. Better yet, use 
`ref` instead of pointer parameters where possible.


These are extern(C) functions written in C. How does one apply @live to 
that? You can't change it to ref in the prototype.


Besides, a deallocation function shouldn't use @live, it's about to 
destroy the pointer.


-Steve

Re: DIP1028 - Rationale for accepting as is

[Petar via Digitalmars-d-announce]

On Friday, 22 May 2020 at 17:12:47 UTC, Atila Neves wrote:

[..]
Yes, there's a cost, which is carefully vetting extern(C) and 
extern(C++) declarations. The decision came down to finding 
this an acceptable trade-off.


How would you feel about a DIP that the only thing it did was 
assume all non-extern (D) code was implciti @trusted? And how 
about if all such code suddenly became @safe without any vetting 
by developers and not even a compiler switch to revert to the old 
behavior?


As evidenced by the community outrage, no one but Walter and 
(maybe) you are convinced that safe-by-default on function bodies 
should imply @safe on non-extern(D) function declarations.


So how about a compromise? We accept a modified version of 
DIP1028 in which safe-by-default applies only to function 
definitions and extern(D) function declarations. And then there's 
a separate compiler switch that changes non-extern (D) function 
declarations to be @trusted? If you like this "feature" you're 
free to use it on your personal projects, but please don't force 
it on everyone who wants @safe to mean anything meaningful.

Re: DIP1028 - Rationale for accepting as is

[Dukc via Digitalmars-d-announce]

The more I think of Atila's and Walter's responses, the more they 
are starting to make sense.


When I look my own code that uses the Nuklear GUI library, 
written in C, it's all `@system`. I have not had the time to make 
`@trusted` wrappers over the BindBC-nuklear API, so I did what 
tends to occur to us as the next best thing: resign and make the 
whole client code `@system`. Just making `@trusted` wrappers over 
BindBC-nuklear seemed to me as inresponsible use of the 
attribute. And reading this theard, it would seem like most of 
you would agree.


But when I think it, what I have accomplised from avoiding that 
antipattern? The only difference is, that if my D code does 
something `@system`, it'll remain under the radar. So I'm worse 
off than had I submitted to the antipattern!


Now, were I designing a library instead of an application, of 
course I should not pass such client code as `@safe`, regardless 
of which of those two ways I choose. But I think the correct way 
would be to mark the API functions as @system. Then it's be best 
of both cheap tricks: The compiler will verify my D code from 
mistakes, but I won't pretend that my code is truly `@safe`.

Re: DIP1028 - Rationale for accepting as is

[Steven Schveighoffer via Digitalmars-d-announce]

On 5/23/20 6:55 AM, Dukc wrote:
The more I think of Atila's and Walter's responses, the more they are 
starting to make sense.


When I look my own code that uses the Nuklear GUI library, written in C, 
it's all `@system`. I have not had the time to make `@trusted` wrappers 
over the BindBC-nuklear API, so I did what tends to occur to us as the 
next best thing: resign and make the whole client code `@system`. Just 
making `@trusted` wrappers over BindBC-nuklear seemed to me as 
inresponsible use of the attribute. And reading this theard, it would 
seem like most of you would agree.


This is fine, the code *is* @system. There's nothing wrong with @system 
code in D.


What is wrong is blanket assumption of @safety. In this case, people who 
actually care about memory safety want to be sure that @safe functions 
are actually @safe. If you lie about that, then the whole system breaks 
down. @safe just becomes a convention, and really everything just has to 
be manually checked.




But when I think it, what I have accomplised from avoiding that 
antipattern? The only difference is, that if my D code does something 
`@system`, it'll remain under the radar. So I'm worse off than had I 
submitted to the antipattern!


I understand what you are saying, you want the @safety checking in your 
code, but do not want to deal with the hassle of making special wrappers.


And let's be honest here, if you are OK with it, putting @trusted: at 
the top of your extern(C) functions is fine with me. At least that's not 
a lie.


What is not fine is having the compiler do it for you so nary a @trusted 
marking is in sight. I don't really understand the draw of that.


-Steve

Re: Work = Resources * Efficiency

[H. S. Teoh via Digitalmars-d-announce]

On Sat, May 23, 2020 at 04:00:35AM -0400, Nick Sabalausky (Abscissa) via 
Digitalmars-d-announce wrote:
[...]
> "Efficiency": Merriam-Webster
> :
> 
> 1: the quality or degree of being efficient ("X is X! Yawn, tell me
> something that means something!")
> 
> 2.a: efficient operation (ehh? Ehhh!?!?!)
[...]

To understand recursion, you must first understand recursion. ;-)


T

-- 
What did the alien say to Schubert? "Take me to your lieder."

Re: DIP 1028--Make @safe the Default--Formal Assessment

[Andrei Alexandrescu via Digitalmars-d-announce]

On 5/21/20 7:49 PM, Bruce Carneal wrote:

On Thursday, 21 May 2020 at 16:32:32 UTC, Adam D. Ruppe wrote:

On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote:
Why we can't we have a technical board where the community can vote 
in experts and potentially companies could even buy a seat for $$$ 
which would mean a lot more for them than the current very vague 
sponsorship options.


ditto, I think we should have like a seven person elected DIP 
committee who pass/fail things by majority vote. It is obvious to me 
that the current process is totally useless.


As noted earlier, I'm with Steve, Seb, Adam, and "everyone but Walter" 
as far as I can see.  If this stands we'll have gone from @safe meaning 
"the compiler is responsible" to "the compiler can't guarantee anything 
unless you're pure D all the way down".


Atila, what's your take on all this?  Is it fork time?


A fork does exist. As expected it went nowhere. 
https://bitbucket.org/larsivi/amber/wiki/Home. There is a paradox about 
forking the language - anyone good enough to lead a successful fork 
would also be wise enough to work on the D language instead.


A committee would work if the community were at least one order of 
magnitude larger. It's just big numbers. Walter is world-class, another 
way of saying there's only a few of comparable strength in the world. A 
larger community would mean a larger likelihood of there being other 
people of comparable strength in it. Those could form a committee. As 
things are, Walter is so much stronger than every one of us, the 
relationship is highly asymmetric. His strength comes with equally 
unique ability to explain and debate, which makes many of the 
discussions in forums very frustrating.

Re: DIP1028 - Rationale for accepting as is

[Petar via Digitalmars-d-announce]

On Friday, 22 May 2020 at 17:12:47 UTC, Atila Neves wrote:

[..]
Yes, there's a cost, which is carefully vetting extern(C) and 
extern(C++) declarations. The decision came down to finding 
this an acceptable trade-off.


How would you feel about a DIP that the only thing it did was 
make all non-extern (D) code implicitly @trusted? And how about 
if all such code suddenly became @safe without any vetting by 
developers and not even a compiler switch to revert to the old 
behavior?
Until DIP1028, putting @trusted: at the start of a module has 
always been considered bad practice and rightfully forbidden in 
libraries with a higher quality bar, such as phobos. But at least 
doing so is honest: you as an author are admitting that you don't 
have time to take care of @safe-ty for now, but it is likely ok 
to assume that the rest of your project is safe (well at least 
the @safe functions) *modulo* the @trusted parts. That way, later 
you can come back and search for @trusted and address those 
issues one by one.


As evidenced by the community outrage, no one but Walter and 
(maybe) you are convinced that safe-by-default on function bodies 
should imply @safe on non-extern(D) function declarations.


---

So how about a compromise?
1. We accept a modified version of DIP1028 in which 
safe-by-default applies only to function definitions and 
extern(D) function declarations.
2. We add a separate compiler switch that changes non-extern (D) 
function declarations to be @trusted.
If you enable 1. and 2. you get the current version of DIP1028, 
but at least corrected, so that extern(C) code @trusted, and not 
@safe.
If you like this "feature" (2.) you're free to use it on your 
personal projects, but please don't force it on everyone who 
wants @safe to be something meaningful.

Codefence, an embeddable interactive code editor, has added D support.

[Paulo Pinto via Digitalmars-d-announce]

Hi everyone,

as the subject states, you can find it here, https://codefence.io/

The current version is 2.092.0 with dmd.

Regards,

Re: DIP1028 - Rationale for accepting as is

[JN via Digitalmars-d-announce]

On Saturday, 23 May 2020 at 12:13:45 UTC, Steven Schveighoffer 
wrote:


What is not fine is having the compiler do it for you so nary a 
@trusted marking is in sight. I don't really understand the 
draw of that.


-Steve


I think not only about how @safe mechanically verifiable is an 
advantage, but also @trusted blocks are very greppable so it's 
easy to find "danger zones" in any project.


I briefly skimmed through the discussion and I don't really see 
the issue with @trusted blocks other than the slightly awkward 
syntax. Yes, it's additional effort, but it should be an 
additional effort, so that people try to avoid unsafe code.


In languages like Rust and C# people are used to using unsafe 
blocks whenever interacting with C code, or people build safe 
wrappers over unsafe APIs, which is exactly what would be 
expected in D after these changes.

Re: BindBC Updates: new loader function, SDL_net, streamlined SDL_* version indentifiers

[Daniel C via Digitalmars-d-announce]

On Saturday, 23 May 2020 at 04:07:35 UTC, Mike Parker wrote:
I suggest you create project/lib and drop the SDL libraries 
there along with the bindbc-sdl library and pass the path to 
the linker. Since you should be using the MS linker (see 
below), it expects the /LIBPATH option 
(https://docs.microsoft.com/en-us/cpp/build/reference/libpath-additional-libpath?view=vs-2019), which you can add to your dmd commandline as `-L/LIBPATH:lib`. Of course, that's assuming you've got the Microsoft Build Tools installed either independently or as part of a Visual Studio installation. If not, you'll be using the LLVM linker that ships with DMD. I believe in that case it should be `-L-Llib`.


If you really want 32-bit and to statically link with the SDL 
import libraries, I strongly recommend you use the -m32mscoff 
dmd options (and the corresponding -ax86_mscoff dub option). 
The SDL libraries are distributed as COFF, not OMF, so using 
OPTLINK would require converting the lib files to OMF first.


Thanks. I did have SDL in a project/lib folder and was trying to 
set LIB and then use -L and other options, but I suppose I borked 
that up as well.  Thanks again for the tips!  I'll be mucking 
around with it again later.

Re: BindBC Updates: new loader function, SDL_net, streamlined SDL_* version indentifiers

[Daniel C via Digitalmars-d-announce]

On Saturday, 23 May 2020 at 03:55:33 UTC, Mike Parker wrote:

On Saturday, 23 May 2020 at 03:25:12 UTC, Daniel C wrote:


This is what I'm getting:
 Error 42: Symbol Undefined 
__D6bindbc3sdl4bind9sdlevents9SDL_Event6__initZ


This isn't a symbol from the SDL library. It's a D symbol from 
the binding.


I figured as much, that's why I tried to link against the 
bindbc-sdl library at first (which then gave me the invalid 
library file error).  I removed it from the line I posted to get 
that message to reappear.


You didn't link with the bindbc-sdl library. But a couple of 
points about that -m32 option:


1. On Windows, DMD always builds with -m32 by default, so you 
don't need to specify it.
2. It means you're using the default OPTLINK linker which 
requires object files in the OMF format.
3. The COFF format is more common in the Windows ecosystem, 
which the -m32mscoff and -m64 options will cause to be generated
4. Unlike DMD, dub will use the system architecture on Windows 
for the default build, meaning on 64-bit Windows it will 
automatically pass -m64 to DMD.


Ugh, I remember running into build issues when I gave D a shot a 
few years ago.  There's a lot of options and specifics that 
aren't very well documented, or at the very least confusing.  In 
the case of Dub, it felt to me like some black box that wasn't 
clear as to what it was doing (even having tried to read the 
documentation a few times).  I felt more in control and aware of 
what was going on with dmd but lol, again I was missing something.



No. You can link to betterC libraries with a normal D app.


Oh, that's good news.  I'll pass that option next time.. or 
actually - I'm not sure what will change in the generated library?


Essentially, the bindbc-sdl library you built is invalid 
because dub built it with -m64 (unless you explicitly passed 
-ax86 on the dub command line) and you built your app with 
-m32, giving you both an architecture mismatch and an object 
file format mismatch.


Then your dmd command is missing the bindbc-sdl library, hence 
the linker error.


Ah.  Dub did do something mischievous after all ;-)  And thanks, 
yeah I'll add the bindbc-sdl library back in after I get my 
command lines straight.  More experimentation ahead.


Thanks so much for your help!

Re: DIP1028 - Rationale for accepting as is

[Arafel via Digitalmars-d-announce]

On 23/5/20 20:40, Johannes T wrote:

On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:

I have made these points before, but I'll summarize them here
for convenient referral.
[..]


Thank you for the detailed and insightful explanation.
Would it be feasible to have a follow-up DIP that enables implicit 
@system extern as an opt-in (e.g. -nosafeextern). The frustration most 
people seem to have with @safe extern is that it lessens the promise of 
@safe without a recourse.


Also there will need to be an answer to this probably inthe future not 
unusual question:


My code is 100% @safe, there's no @trusted block anywhere, why am I 
getting memory corruption?


To me the expectation / promise was that @safe code was safe from memory 
corruption modulo bugs in the implementation.


The only source for issues would be then @trusted code that could be 
audited as needed.


You could say "well, you always had to check for those", but the 
difference is that until now the compiler would shout at me if I didn't, 
so I wouldn't forget about them.


Now it has to be clearly explained that you should check for @trusted 
code AND unmarked external C functions.

Re: Codefence, an embeddable interactive code editor, has added D support.

[Paulo Pinto via Digitalmars-d-announce]

On Saturday, 23 May 2020 at 19:49:33 UTC, welkam wrote:

On Saturday, 23 May 2020 at 15:04:35 UTC, Paulo Pinto wrote:

Hi everyone,

as the subject states, you can find it here, 
https://codefence.io/


The current version is 2.092.0 with dmd.

Regards,


Why such thing is free? Who pays for the servers?


No idea, I just found it while browsing Reddit.

Re: Codefence, an embeddable interactive code editor, has added D support.

[welkam via Digitalmars-d-announce]

On Saturday, 23 May 2020 at 15:04:35 UTC, Paulo Pinto wrote:

Hi everyone,

as the subject states, you can find it here, 
https://codefence.io/


The current version is 2.092.0 with dmd.

Regards,


Why such thing is free? Who pays for the servers?

Re: DIP1028 - Rationale for accepting as is

[ag0aep6g via Digitalmars-d-announce]

On 23.05.20 21:46, Arafel wrote:
Now it has to be clearly explained that you should check for @trusted 
code AND unmarked external C functions.


... and @system static constructors and `--boundscheck=off` and 
initializers of globals

Re: Codefence, an embeddable interactive code editor, has added D support.

[aberba via Digitalmars-d-announce]

On Saturday, 23 May 2020 at 15:04:35 UTC, Paulo Pinto wrote:

Hi everyone,

as the subject states, you can find it here, 
https://codefence.io/


The current version is 2.092.0 with dmd.

Regards,


Nice. Very useful. Imagine something like this for the D blog

Re: DIP1028 - Rationale for accepting as is

[H. S. Teoh via Digitalmars-d-announce]

On Sat, May 23, 2020 at 10:55:40AM +, Dukc via Digitalmars-d-announce wrote:
[...]
> When I look my own code that uses the Nuklear GUI library, written in
> C, it's all `@system`. I have not had the time to make `@trusted`
> wrappers over the BindBC-nuklear API, so I did what tends to occur to
> us as the next best thing: resign and make the whole client code
> `@system`. Just making `@trusted` wrappers over BindBC-nuklear seemed
> to me as inresponsible use of the attribute. And reading this theard,
> it would seem like most of you would agree.
> 
> But when I think it, what I have accomplised from avoiding that
> antipattern?  The only difference is, that if my D code does something
> `@system`, it'll remain under the radar. So I'm worse off than had I
> submitted to the antipattern!
[...]

And this is precisely why I proposed that what we need is a way for the
compiler to mechanically check all code *except* certain specified
blackboxes that are skipped over.  Then you can have your calls to
unvetted C functions and still have the mechanical checks enabled for
the rest of your code.

This is also related to @trusted blocks inside a function, the intention
of which is to limit the @system code to as small a surface area as
possible while enabling @safe checks for the rest of the function.


T

-- 
Gone Chopin. Bach in a minuet.

Re: DIP1028 - Rationale for accepting as is

[Paul Backus via Digitalmars-d-announce]

On Saturday, 23 May 2020 at 15:33:05 UTC, H. S. Teoh wrote:

On Sat, May 23, 2020 at 10:55:40AM +

And this is precisely why I proposed that what we need is a way 
for the compiler to mechanically check all code *except* 
certain specified blackboxes that are skipped over.  Then you 
can have your calls to unvetted C functions and still have the 
mechanical checks enabled for the rest of your code.


This is also related to @trusted blocks inside a function, the 
intention of which is to limit the @system code to as small a 
surface area as possible while enabling @safe checks for the 
rest of the function.



T


@system void foo(...) {
() @safe {
// mechanically checked
}();
// not checked
}

Re: DIP1028 - Rationale for accepting as is

[Johannes T via Digitalmars-d-announce]

On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:

I have made these points before, but I'll summarize them here
for convenient referral.
[..]


Thank you for the detailed and insightful explanation.
Would it be feasible to have a follow-up DIP that enables 
implicit @system extern as an opt-in (e.g. -nosafeextern). The 
frustration most people seem to have with @safe extern is that it 
lessens the promise of @safe without a recourse.

Re: DIP1028 - Rationale for accepting as is

[Arafel via Digitalmars-d-announce]

On 24/5/20 0:02, ag0aep6g wrote:


... and @system static constructors and `--boundscheck=off` and 
initializers of globals


Other than `--boundscheck=off`, that is presumably actively chosen by 
the user (as is @trust), would the others be allowed without `@trusted` 
in otherwise 100% @safe code?


I would find concerning that any @system code is allowed, but I guess 
initializers of globals should be ok as long as they are @safe themselves?

Re: DIP 1028--Make @safe the Default--Formal Assessment

[Walter Bright via Digitalmars-d-announce]

On 5/23/2020 4:26 AM, Faux Amis wrote:
Just a suggestion, but sometimes matters are best discussed over audio/video. 
Would having a public teams/zoom/.. meeting be helpful?


I would definitely listen/watch; even if I were muted and could only chat maybe.


You're right, and that is the whole purpose behind DConf. It's amazing how our 
differences melt away when discussing with a beer in hand :-)

Re: DIP1028 - Rationale for accepting as is

[ag0aep6g via Digitalmars-d-announce]

On 24.05.20 00:17, Arafel wrote:

On 24/5/20 0:02, ag0aep6g wrote:


... and @system static constructors and `--boundscheck=off` and 
initializers of globals


Other than `--boundscheck=off`, that is presumably actively chosen by 
the user (as is @trust), would the others be allowed without `@trusted` 
in otherwise 100% @safe code?


Yup. Today they can be unmarked, defaulting to @system. With DIP 1028, 
they can be explicitly marked @system. Either way, they don't show up 
when you only look for "@trusted".


I would find concerning that any @system code is allowed, but I guess 
initializers of globals should be ok as long as they are @safe themselves?


As long as they're @safe, sure. But they can also be @system.

An example:

const int x = 42;
const int y = 43;

void main() @safe
{
import std.stdio;
writeln(x, " ", y); /* Prints "42 43" as expected. */
auto px = 
auto py = 
writeln(*px, " ", *py); /* Prints "13 14". Wat? */
}

int* p = cast(int*) 
static this() @system { *p = 13; *++p = 14; }

Re: DIP1028 - Rationale for accepting as is

[Arine via Digitalmars-d-announce]

On Saturday, 23 May 2020 at 22:38:58 UTC, ag0aep6g wrote:

On 24.05.20 00:17, Arafel wrote:

On 24/5/20 0:02, ag0aep6g wrote:


... and @system static constructors and `--boundscheck=off` 
and initializers of globals


Other than `--boundscheck=off`, that is presumably actively 
chosen by the user (as is @trust), would the others be allowed 
without `@trusted` in otherwise 100% @safe code?


Yup. Today they can be unmarked, defaulting to @system. With 
DIP 1028, they can be explicitly marked @system. Either way, 
they don't show up when you only look for "@trusted".


I would find concerning that any @system code is allowed, but 
I guess initializers of globals should be ok as long as they 
are @safe themselves?


As long as they're @safe, sure. But they can also be @system.

An example:

const int x = 42;
const int y = 43;

void main() @safe
{
import std.stdio;
writeln(x, " ", y); /* Prints "42 43" as expected. */
auto px = 
auto py = 
writeln(*px, " ", *py); /* Prints "13 14". Wat? */
}

int* p = cast(int*) 
static this() @system { *p = 13; *++p = 14; }



That works even if you make the static this() @safe, and remove 
the pointer incrementation.


You'd have to make the p initialization @safe.

@safe:
int* p = cast(int*)  // error

But note this doesn't work:

@safe int* p = cast(int*)  // compiles

Having the default become @safe will help detect this, as I don't 
imagine that is a whole lot of usage of @safe: to begin with.

Re: BindBC Updates: new loader function, SDL_net, streamlined SDL_* version indentifiers

[Daniel C via Digitalmars-d-announce]

On Saturday, 23 May 2020 at 19:59:51 UTC, Daniel C wrote:

I'll be mucking around with it again later.


Well, I'm having limited success.  I got 32-bit compile/run using 
basic -m32, and -m64 compiles but crashes lol.  Trying out 32-bit 
-m32mscoff with Microsoft Build Tools (2019) resulted in this 
mess:
phobos32mscoff.lib(runtime_c8b_76e.obj) : error LNK2001: 
unresolved external sym

bol _printf
phobos32mscoff.lib(parseoptions_d98_7cf.obj) : error LNK2001: 
unresolved externa

l symbol _printf
phobos32mscoff.lib(gc_244f_122.obj) : error LNK2001: unresolved 
external symbol

_printf
phobos32mscoff.lib(msvc_32mscoff.obj) : error LNK2001: unresolved 
external symbo

l __vsnprintf
phobos32mscoff.lib(parseoptions_d93_21b.obj) : error LNK2001: 
unresolved externa

l symbol _sscanf

Frustrating!  I don't even know where to go for help with that 
stuff.  Through experimentation, I was able to compile with older 
Visual C++ 2010 tools, but I'd rather not be using 10 year old 
tech.


Maybe this wasn't the time for me to come back lol

Re: BindBC Updates: new loader function, SDL_net, streamlined SDL_* version indentifiers

[Mike Parker via Digitalmars-d-announce]

On Sunday, 24 May 2020 at 04:16:10 UTC, Daniel C wrote:

On Saturday, 23 May 2020 at 19:59:51 UTC, Daniel C wrote:

I'll be mucking around with it again later.


Well, I'm having limited success.  I got 32-bit compile/run 
using basic -m32, and -m64 compiles but crashes lol.  Trying 
out 32-bit -m32mscoff with Microsoft Build Tools (2019) 
resulted in this mess:
phobos32mscoff.lib(runtime_c8b_76e.obj) : error LNK2001: 
unresolved external sym

bol _printf
phobos32mscoff.lib(parseoptions_d98_7cf.obj) : error LNK2001: 
unresolved externa

l symbol _printf
phobos32mscoff.lib(gc_244f_122.obj) : error LNK2001: unresolved 
external symbol

_printf
phobos32mscoff.lib(msvc_32mscoff.obj) : error LNK2001: 
unresolved external symbo

l __vsnprintf
phobos32mscoff.lib(parseoptions_d93_21b.obj) : error LNK2001: 
unresolved externa

l symbol _sscanf

Frustrating!  I don't even know where to go for help with that 
stuff.  Through experimentation, I was able to compile with 
older Visual C++ 2010 tools, but I'd rather not be using 10 
year old tech.


There should be no need to revert to VS 2010. These errors 
indicate that something in your build process or setup is borked.


Have you tried building your app with dub and using bindbc-sdl as 
a dependency rather than doing it separately DMD? This way, you 
can ensure that everything is being compiled with the same 
options and the linker is getting the correct libraries.




Maybe this wasn't the time for me to come back lol


I would say it's generally much easier to build D projects these 
days than it ever has been. We just need to figure out where 
you're going wrong.

Re: DIP 1028--Make @safe the Default--Formal Assessment

[ag0aep6g via Digitalmars-d-announce]

On 23.05.20 17:07, Andrei Alexandrescu wrote:
A fork does exist. As expected it went nowhere. 
https://bitbucket.org/larsivi/amber/wiki/Home. There is a paradox about 
forking the language - anyone good enough to lead a successful fork 
would also be wise enough to work on the D language instead.


I can only read that as you calling larsivi not "good enough to lead a 
successful fork" and not "wise enough to work on the D language instead".


Walter says: "Belittling [others] [...] is unprofessional behavior."

He was refering to other people on the forum, of course. But I would 
expand that to authors of other projects as well, particularly ones that 
are (even) smaller than D. Punching down is not cool.

Re: DIP 1028--Make @safe the Default--Formal Assessment

[Andrei Alexandrescu via Digitalmars-d-announce]

On 5/23/20 6:49 PM, ag0aep6g wrote:

On 23.05.20 17:07, Andrei Alexandrescu wrote:
A fork does exist. As expected it went nowhere. 
https://bitbucket.org/larsivi/amber/wiki/Home. There is a paradox 
about forking the language - anyone good enough to lead a successful 
fork would also be wise enough to work on the D language instead.


I can only read that as you calling larsivi not "good enough to lead a 
successful fork" and not "wise enough to work on the D language instead".


Walter says: "Belittling [others] [...] is unprofessional behavior."

He was refering to other people on the forum, of course. But I would 
expand that to authors of other projects as well, particularly ones that 
are (even) smaller than D. Punching down is not cool.


The point is on the other side - the barrier is very high. Carrying a 
programming language design and implementation is an extremely difficult 
task.

Re: DIP1028 - Rationale for accepting as is

[ag0aep6g via Digitalmars-d-announce]

On 24.05.20 02:55, Arine wrote:
That works even if you make the static this() @safe, and remove the 
pointer incrementation.


Sure. `*p = 13;` is perfectly @safe. The static constructor isn't needed 
for that part. You can just as well do the assignment in `main`. The 
static constructor is another feature that can smuggle unsafe code (the 
increment) into your program without the @trusted warning label.



You'd have to make the p initialization @safe.

     @safe:
     int* p = cast(int*)  // error

But note this doesn't work:

     @safe int* p = cast(int*)  // compiles

Having the default become @safe will help detect this, as I don't 
imagine that is a whole lot of usage of @safe: to begin with.


The example compiles with `-preview=safedefault`. And even if that gets 
changed, it will probably still compile when marked @system. So we still 
won't find it when looking for "@trusted".

Re: DIP1028 - Rationale for accepting as is

[Arafel via Digitalmars-d-announce]

On 24/5/20 0:38, ag0aep6g wrote:

On 24.05.20 00:17, Arafel wrote:

On 24/5/20 0:02, ag0aep6g wrote:


... and @system static constructors and `--boundscheck=off` and 
initializers of globals


Other than `--boundscheck=off`, that is presumably actively chosen by 
the user (as is @trust), would the others be allowed without 
`@trusted` in otherwise 100% @safe code?


Yup. Today they can be unmarked, defaulting to @system. With DIP 1028, 
they can be explicitly marked @system. Either way, they don't show up 
when you only look for "@trusted".


I would find concerning that any @system code is allowed, but I guess 
initializers of globals should be ok as long as they are @safe 
themselves?


As long as they're @safe, sure. But they can also be @system.

An example:

const int x = 42;
const int y = 43;

void main() @safe
{
     import std.stdio;
     writeln(x, " ", y); /* Prints "42 43" as expected. */
     auto px = 
     auto py = 
     writeln(*px, " ", *py); /* Prints "13 14". Wat? */
}

int* p = cast(int*) 
static this() @system { *p = 13; *++p = 14; }




I find this... disturbing... what is worse, it also happens with 
`immutable`.


Then there should most definitely be a list of features to look (in 
addition to `@trusted`) if you want to make sure your `@safe` code is 
actually safe.

Re: DIP 1028--Make @safe the Default--Formal Assessment

[Arine via Digitalmars-d-announce]

On Saturday, 23 May 2020 at 15:07:16 UTC, Andrei Alexandrescu 
wrote:

On 5/21/20 7:49 PM, Bruce Carneal wrote:

On Thursday, 21 May 2020 at 16:32:32 UTC, Adam D. Ruppe wrote:

On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote:
Why we can't we have a technical board where the community 
can vote in experts and potentially companies could even buy 
a seat for $$$ which would mean a lot more for them than the 
current very vague sponsorship options.


ditto, I think we should have like a seven person elected DIP 
committee who pass/fail things by majority vote. It is 
obvious to me that the current process is totally useless.


As noted earlier, I'm with Steve, Seb, Adam, and "everyone but 
Walter" as far as I can see.  If this stands we'll have gone 
from @safe meaning "the compiler is responsible" to "the 
compiler can't guarantee anything unless you're pure D all the 
way down".


Atila, what's your take on all this?  Is it fork time?


A fork does exist. As expected it went nowhere. 
https://bitbucket.org/larsivi/amber/wiki/Home. There is a 
paradox about forking the language - anyone good enough to lead 
a successful fork would also be wise enough to work on the D 
language instead.


Arguably they would then be wise enough to stay away from D (and 
have).


His strength comes with equally unique ability to explain and 
debate, which makes many of the discussions in forums very 
frustrating.


It is unique that's for sure. That's a good way to put it without 
being rude.

Re: DIP1028 - Rationale for accepting as is

[Walter Bright via Digitalmars-d-announce]

On 5/22/2020 10:25 AM, Timon Gehr wrote:

With the o/b system `free` might actually work out OK


free(new int);


I did mention in the documentation that when using different memory allocators, 
mixing them up will not be detected. You'd have to declare the allocators using 
specific pointer types, rather than void*.

Re: DIP1028 - Rationale for accepting as is

[Walter Bright via Digitalmars-d-announce]

I'd like to emphasize:

1. It is not possible for the compiler to check any declarations where the 
implementation is not available. Not in D, not in any language. Declaring a 
declaration safe does not make it safe.


2. If un-annotated declarations cause a compile time error, it is highly likely 
the programmer will resort to "greenwashing" - just slapping @safe on it. I've 
greenwashed code. Atila has. Bruce Eckel has. We've all done it. Sometimes even 
for good reasons.


3. Un-annotated declarations are easily detectable in a code review.

4. Greenwashing is not easily detectable in a code review.

5. Greenwashing doesn't fix anything. The code is not safer. It's an illusion, 
not a guarantee.


6. If someone cares to annotate declarations, it means he has at least thought 
about it, because he doesn't need to. Hence it's more likely to be correct than 
when greenwashed.


7. D should *not* make it worthwhile for people to greenwash code.

It is, in a not-at-all obvious way, safer for C declarations to default to being 
safe.

Re: DIP1028 - Rationale for accepting as is

[Timon Gehr via Digitalmars-d-announce]

On 24.05.20 05:28, Walter Bright wrote:

I'd like to emphasize:



I understand all of those points and most of them are true, and obvious.

The issue is that they are not a justification for the decision. You 
seem to think that greenwashing is not greenwashing when it is done by 
the compiler without user interaction. Why is that?


1. It is not possible for the compiler to check any declarations where 
the implementation is not available. Not in D, not in any language. 
Declaring a declaration safe does not make it safe.

...


Which is exactly why it should not be possible to declare it @safe.

2. If un-annotated declarations cause a compile time error, it is highly 
likely the programmer will resort to "greenwashing" - just slapping 
@safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've 
all done it. Sometimes even for good reasons.

...


Slapping @safe on it should not even compile. You should slap either 
@system or @trusted on it.



3. Un-annotated declarations are easily detectable in a code review.
...


It's easier to find something that is there than something that is not 
there. Greenwashing is not easier to detect if the compiler did it 
implicitly.



4. Greenwashing is not easily detectable in a code review.
...


Even though it is easy to miss in a code review, it's easy to detect 
automatically. Any extern(C) prototype that is annotated @safe 
(explicitly or implicitly) is greenwashed.



5. Greenwashing doesn't fix anything. The code is not safer.


Actually further down you say that it makes the code safer in a 
"not-at-all obvious way". Which is it?



It's an illusion, not a guarantee.
...


Yes. On the other hand, @trusted is not an illusion, it is a way to 
clarify responsibilities.


6. If someone cares to annotate declarations, it means he has at least 
thought about it, because he doesn't need to.


True, but this is an argument against restrictive defaults in general, 
in particular @safe by default. Also note that if someone cares to 
annotate declarations, the compiler pointing out missing annotations 
that would otherwise cause implicit greenwashing is _useful_.



Hence it's more likely to be correct than when greenwashed.
...


This is true whether or not the compiler does the greenwashing 
implicitly. Annotating with @safe is a lie, whether the compiler does it 
or the programmer. It should be rejected and force @system or @trusted. 
You can still quickly see a difference in applied care by checking 
whether it's a single @trusted: or each prototype is annotated individually.



7. D should *not* make it worthwhile for people to greenwash code.
...


Greenwashing automatically is not a solution, it's admitting defeat. Why 
can't the compiler just reject greenwashing with @safe?
Slapping @trusted on prototypes is not greenwashing, it's saying "I take 
responsibility for the memory safety of this external C code".


It is, in a not-at-all obvious way, safer for C declarations to default 
to being safe.


@safe is advertised to give mechanical guarantees, where @trusted is a 
way for programmers to take responsibility for parts of the code. It is 
not advertised to be an unsound linter with pseudo-pragmatic trade-offs 
and implicit false negatives.