On Friday, 28 July 2017 at 12:40:06 UTC, Kagamin wrote:
> On Wednesday, 26 July 2017 at 17:48:21 UTC, Walter Bright wrote:
>> On 7/26/2017 6:29 AM, Kagamin wrote:
>>> Should we still try to mark them safe at all?
>>
>> Marking ones that are safe with @safe is fine. OS APIs pretty much never change.
>
> New technologies and new features get introduced over time: 64 bit, ipv6, bitmap_v5, generally bigger data everywhere, and api changes accordingly and incorporates new features, and takes increasingly bigger arguments over time.

most of them don't lead to "real" API changes, they often only add new functions/overloads/whatever

> There's a less questionable problem with it.

Hint: FILE struct is transparent, look inside it, lots of interesting stuff there.

On Wednesday, 26 July 2017 at 17:48:21 UTC, Walter Bright wrote:
> On 7/26/2017 6:29 AM, Kagamin wrote:
>> Should we still try to mark them safe at all?
>
> Marking ones that are safe with @safe is fine. OS APIs pretty much never change.

Sometimes operating systems add new flags to their API which change how some values are interpreted. Some API functions may, for example, normally take a pointer to a such-and-such struct, but if a certain flag is specified, the parameter is instead interpreted as a pointer to a different data type. That would be one case where an API call becomes un-@safe due to the addition of a flag.

On 31/07/17 16:33, Vladimir Panteleev wrote:
> On Wednesday, 26 July 2017 at 17:48:21 UTC, Walter Bright wrote:
>> On 7/26/2017 6:29 AM, Kagamin wrote:
>>> Should we still try to mark them safe at all?
>>
>> Marking ones that are safe with @safe is fine. OS APIs pretty much never change.
> 
> Sometimes operating systems add new flags to their API which change how some values are interpreted. Some API functions may, for example, normally take a pointer to a such-and-such struct, but if a certain flag is specified, the parameter is instead interpreted as a pointer to a different data type. That would be one case where an API call becomes un-@safe due to the addition of a flag.
> 

One of the things that really bother me with the D community is the "100% or nothing" approach.

System programming is, by definition, an exercise in juggling conflicting aims. The more absolute the language, the less useful it is for performing real life tasks.

Shachar

On 31.07.2017 15:56, Shachar Shemesh wrote:
> 
> One of the things that really bother me with the D community is the "100% or nothing" approach.
> ...

Personally, I'm more bothered by this kind of lazy argument that sounds good but has no substance.

> System programming is, by definition, an exercise in juggling conflicting aims. The more absolute the language, the less useful it is for performing real life tasks.

Why do you think @trusted exists?

On 31/07/17 17:08, Timon Gehr wrote:
> On 31.07.2017 15:56, Shachar Shemesh wrote:
>>
>> One of the things that really bother me with the D community is the "100% or nothing" approach.
>> ...
> 
> Personally, I'm more bothered by this kind of lazy argument that sounds good but has no substance.
> 
>> System programming is, by definition, an exercise in juggling conflicting aims. The more absolute the language, the less useful it is for performing real life tasks.
> 
> Why do you think @trusted exists?

That's fine, but since, according to the logic presented here, no OS function can ever be @safe, then all code calling such a function can't be @safe either. At this point, half your code, give or take, is @trusted. That's the point you give up, and just write everything as @system.

And what we have here is that you started out trying to be 100% pure (and, in this case, there is no problem with current code, only *hypothetical* future changes), and end up not getting any protection from @safe at all.

There is a proverb in Hebrew that says:
תפסת מרובה, לא תפסת.
Try to grab too much, and you end up holding nothing.

Shachar

On 31.07.2017 16:15, Shachar Shemesh wrote:
>>
>> Why do you think @trusted exists?
> 
> That's fine, but since, according to the logic presented here, no OS function can ever be @safe,

This is actually not true. Vladimir was just pointing out a complication of which to be aware. Are you arguing against applying due diligence when specifying library interfaces?

> 
> There is a proverb in Hebrew that says:
> תפסת מרובה, לא תפסת.
> Try to grab too much, and you end up holding nothing. 

I.e. if you mark too many functions as @trusted, you will have no memory safety.

On Monday, 31 July 2017 at 14:51:22 UTC, Timon Gehr wrote:
> On 31.07.2017 16:15, Shachar Shemesh wrote:
>> That's fine, but since, according to the logic presented here, no OS function can ever be @safe,
>
> This is actually not true. Vladimir was just pointing out a complication of which to be aware. Are you arguing against applying due diligence when specifying library interfaces?

Indeed. @safe is not a sandbox, there is no need to actually go to extreme measures to safeguard against potential changes beyond our control; just something to keep in mind.

On Monday, 31 July 2017 at 13:56:48 UTC, Shachar Shemesh wrote:
> One of the things that really bother me with the D community is the "100% or nothing" approach.

In the worst case when a function becomes unsafe, only @safe attribute will be removed from it, which will be a breaking change, but hopefully it will happen rarely enough.

Direct OS function calls should probably all be treated as unsafe, except for rare cases where the behaviour is very well defined in standards and in actual implementations to be safe. The way to get safe functions for OS functionality is to write wrapper functions in D which prohibit unsafe calls.