On Thursday, 28 May 2020 at 16:47:01 UTC, Steven Schveighoffer wrote:
> On 5/28/20 12:39 PM, Adam D. Ruppe wrote:
>> On Thursday, 28 May 2020 at 15:12:56 UTC, Steven Schveighoffer wrote:
>>> 2. If we went to an "inferred-by-default" regime, there would have to be a way to opt-out of it, to allow for crafting attributes of public extern functions.
>> 
>> You'd just have to write them out there.
>
> Not possible in some cases (@throws, @gc, @impure)
>
>> 
>>> 4. Documentation should show the inferred attributes IMO (not sure if this already happens for auto functions for example).
>> 
>> Eeeeeeh, I'd be ok with that but it would need to actually point out that it was inferred - that this is NOT a promise of forward compatibility, it just happens to be so in this version
>
> Sure, that's a reasonable expectation.
>
> -steve

I'm a fan of your auto-inference or inferred-by-default or whatever you'd like to call it ideas.  Wider utility and less "annotation soup".

If you've got the time, I'd suggest your starting a new thread.  Now that Walter has withdrawn 1028 we could really use something to amp up @safe, and other attribute, utility.

Am Thu, 28 May 2020 23:35:48 +0000 schrieb Adam D. Ruppe:

> On Thursday, 28 May 2020 at 22:56:15 UTC, Andrei Alexandrescu wrote:
>> Large projects separate compilation inter-procedural analysis does not scale yadda yadda yadda.
> 
> We need to stop making assertions without measurements. This may be true, but it needs to be based on empirical fact - the one thing we should notice is compile speed is sensitive to surprising things and not to other surprising things....

Unfortunately what really limits us here is the C/C++ toolchain ecosystem (linker, library loader...). Ideally we'd do an attribute inference / code generation / inline information generation (function 'classification') pass exactly once per module, then store the information in some sort of compiled intermediary file. For (cross-module) inlining, this is essentially what LTO does. But I don't know whether you could include enough other information, such as function prototypes for all analyzed functions...

Maybe it'd make sense to store this information to separate files, but then it's more difficult again to integrate into current toolflows.


-- 
Johannes

Am Thu, 28 May 2020 16:39:21 +0000 schrieb Adam D. Ruppe:

> On Thursday, 28 May 2020 at 15:12:56 UTC, Steven Schveighoffer wrote:
>> 2. If we went to an "inferred-by-default" regime, there would have to be a way to opt-out of it, to allow for crafting attributes of public extern functions.
> 
> You'd just have to write them out there.

I haven't though about it a lot, but I think I'd prefer to have stable library ABIs by default. So at least all export-ed, non-templated functions should not have inference.

Otherwise we'd have to add a best-practice 'fully annotate all exported function to avoid ABI breakage' rule, which then again is some sort of programming by convention...

-- 
Johannes

On Friday, 29 May 2020 at 06:26:29 UTC, Johannes Pfau wrote:
> Am Thu, 28 May 2020 16:39:21 +0000 schrieb Adam D. Ruppe:
>
>> On Thursday, 28 May 2020 at 15:12:56 UTC, Steven Schveighoffer wrote:
>>> 2. If we went to an "inferred-by-default" regime, there would have to be a way to opt-out of it, to allow for crafting attributes of public extern functions.
>> 
>> You'd just have to write them out there.
>
> I haven't though about it a lot, but I think I'd prefer to have stable library ABIs by default. So at least all export-ed, non-templated functions should not have inference.
>
> Otherwise we'd have to add a best-practice 'fully annotate all exported function to avoid ABI breakage' rule, which then again is some sort of programming by convention...

Unless it's believed that the separate compilation capability is both essential and plausibly intractable, experimenting with the "I have all the source code" subset first seems like a good idea.  For one, I'm pretty sure that we can find a way to store/retrieve compiler inferences.

On 28.05.20 22:41, Meta wrote:
> On Thursday, 28 May 2020 at 00:31:09 UTC, Jonathan M Davis wrote:
>> On Wednesday, May 27, 2020 5:57:00 PM MDT Meta via Digitalmars-d wrote:
>>> On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis wrote:
>>> > Based on some of Walter's comments, it also sounds like he > 
>>> intends to make nothrow the default in another DIP, which is > also a terrible idea. I'm increasingly worried about the > future of D with some of where these DIPs are going.
>>> >
>>> > - Jonathan M Davis
>>>
>>> What's wrong with nothrow by default? Probably 97% of code doesn't need to throw exceptions.
>>
>> If anything, I would say the opposite.
>>
>> <snip>
> 
> I find that response surprising, given that you used to use Haskell (do you still?), which gets along fine without exceptions.

http://hackage.haskell.org/package/base-4.14.0.0/docs/Control-Exception.html

Furthermore, imperative-style code in Haskell is based on monads, which are a generalization of exceptions.

On Thursday, 28 May 2020 at 23:35:48 UTC, Adam D. Ruppe wrote:
> On Thursday, 28 May 2020 at 22:56:15 UTC, Andrei Alexandrescu wrote:
>> Large projects separate compilation inter-procedural analysis does not scale yadda yadda yadda.
>
> We need to stop making assertions without measurements. This may be true, but it needs to be based on empirical fact - the one thing we should notice is compile speed is sensitive to surprising things and not to other surprising things....

It's not surprising that copying a CompoundStatement all over the place and then discarding most of it is a waste.

On Friday, 29 May 2020 at 08:52:14 UTC, Timon Gehr wrote:
>> I find that response surprising, given that you used to use Haskell (do you still?), which gets along fine without exceptions.
>
> http://hackage.haskell.org/package/base-4.14.0.0/docs/Control-Exception.html
>
> Furthermore, imperative-style code in Haskell is based on monads, which are a generalization of exceptions.

I'm going to step up the pedantry and say that this proves my assertion; Haskell (the language) gets along fine without exceptions, but they're there for you to use as a library, only if you want to.

On 5/28/20 7:35 PM, Adam D. Ruppe wrote:
> On Thursday, 28 May 2020 at 22:56:15 UTC, Andrei Alexandrescu wrote:
>> Large projects separate compilation inter-procedural analysis does not scale yadda yadda yadda.
> 
> We need to stop making assertions without measurements. This may be true, but it needs to be based on empirical fact - the one thing we should notice is compile speed is sensitive to surprising things and not to other surprising things....

Needs to be based in sound analysis, not measurements, as a quadratic is not scalable regardless of the constant. When I was in the field there was no escaping this fact, and all interprocedural analyses that did anything interesting were limited to programs a few KB in size.

Perhaps things have improved since, and it would be great if they did. Timon should know about this.

On Friday, 29 May 2020 at 12:40:45 UTC, Meta wrote:
> On Friday, 29 May 2020 at 08:52:14 UTC, Timon Gehr wrote:
>>> I find that response surprising, given that you used to use Haskell (do you still?), which gets along fine without exceptions.
>>
>> http://hackage.haskell.org/package/base-4.14.0.0/docs/Control-Exception.html
>>
>> Furthermore, imperative-style code in Haskell is based on monads, which are a generalization of exceptions.
>
> I'm going to step up the pedantry and say that this proves my assertion; Haskell (the language) gets along fine without exceptions, but they're there for you to use as a library, only if you want to.

Forgoing exceptions in D would be a lot more palatable if we had something like C++'s [[nodiscard]] and Rust's #[must_use]. Currently, if you want to ensure that callers of your function can't ignore errors by accident, your only option in D is to throw an exception.

On Friday, 29 May 2020 at 13:20:52 UTC, Paul Backus wrote:
> On Friday, 29 May 2020 at 12:40:45 UTC, Meta wrote:
>> I'm going to step up the pedantry and say that this proves my assertion; Haskell (the language) gets along fine without exceptions, but they're there for you to use as a library, only if you want to.
>
> Forgoing exceptions in D would be a lot more palatable if we had something like C++'s [[nodiscard]] and Rust's #[must_use]. Currently, if you want to ensure that callers of your function can't ignore errors by accident, your only option in D is to throw an exception.

I agree, it would be nice to be able to express that in D. You can sort of emulate it at runtime:

struct MustUse(T)
{
    T payload;
    bool used;

    ref T use() { used = true; return payload; }
    alias use this; //Or, probably better, call use() manually

    ~this() { assert(used, MustUse.stringof ~ " must be used, but it wasn't"); }
}

MustUse!string read(File f) { ... }