There's a discussion that may be of interest to the larger community: https://github.com/D-Programming-Language/dmd/pull/1877

Andrei

On Tue, 16 Apr 2013 16:22:56 +0100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> There's a discussion that may be of interest to the larger community: https://github.com/D-Programming-Language/dmd/pull/1877

I read the whole thing and IMO this pull request is a good idea.

I think your last summary covers the various points well:
https://github.com/D-Programming-Language/dmd/pull/1877#issuecomment-16403663

Should the first step here be to fix the issue described in 2.1?  I agree with your reasoning that (b) seems a decent solution.  We don't want 'auto' function bodies in .di files and /more importantly/ IMO interface definitions should be as precise as possible.

I would almost suggest that good working practice may be to use auto in the .d file, generate the precise .di then back-port the precise .di definition to the .d file once development was complete (for any given version of the library).

This would then make accidental changes to a library interface difficult because and change to the library source which conflicted with the now precise definition would be flagged by the compiler.  That is, unless you're doing something nasty with void* and cast or similar.

It seems the remaining complaint is the compilation speed issue.

Do people recompile .di files with every change?

I can imagine if you're in a development loop which involves updating a library, recompiling it, moving to a consumer of that library, updating that and recompiling, then testing the change, then looping back to make more changes, and so on.  In this case it is conceivable that a library changes might result in a .di change, which would then result in more recompilation right through.

But .. if the .di changes it will do so because the library interface has changed, and those changes are surely important to the consumer, aren't they?

Or, is there a sufficiently large sub-set of possible changes you could make to the library which are irrelevant to the consumer?

If that is the case, can .di generation from 'auto' leave these off the precise definition?  I mean, if we're saying they're irrelevant to the consumer of the library, why put them there in the first place, right?

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

16-Apr-2013 19:22, Andrei Alexandrescu пишет:
> There's a discussion that may be of interest to the larger community:
> https://github.com/D-Programming-Language/dmd/pull/1877
>
> Andrei

In the same vane - how about attribute inference for "ordinary" functions?

I recall that just a month ago I had an interesting case - a normal function inside of a templated struct. The thing is that depending on some parameters (of struct) it could be safe or not. But it's not a template itself and its return type is always bool.

In the end I just added an empty CT parameter set making it a template.

Questions are - why are we hell bent on the `auto' return type being a marker? What are the other good markers out there? Should we pick anything else for this auto-magic or let the programmer use some wild-card marker explicitly?

If we let a bunch of arcane rules govern the inference that would be a failure. On the other hand not doing it where makes sense would be a failure to realize the benefits of annotations ('cause nobody bothers adding them explicitly).

-- 
Dmitry Olshansky

This is the point I have a problem with:

>> 2.2. One cannot opt out of nothrow or pure with auto functions.
> This argument has one solid answer: don't use auto when the need is to specify an attribute pattern explicitly.

I find this unacceptable. Thanks to the proliferation of template code in D, it is often rather difficult to spell out return types. Indeed, this is part of the original reason for auto's existence. Denying return type deduction for this use case is a major inconvenience.

As it stands, I am against this change.

It is an unfortunate situation we are in, with D working best with everything inferred and CTFE-able, yet with those things completely at odds with modularity.

On 04/16/2013 07:06 PM, Dmitry Olshansky wrote:
> 16-Apr-2013 19:22, Andrei Alexandrescu пишет:
>> There's a discussion that may be of interest to the larger community:
>> https://github.com/D-Programming-Language/dmd/pull/1877
>>
>> Andrei
>
> In the same vane - how about attribute inference for "ordinary" functions?
>
> I recall that just a month ago I had an interesting case - a normal
> function inside of a templated struct. The thing is that depending on
> some parameters (of struct) it could be safe or not. But it's not a
> template itself and its return type is always bool.
>
> In the end I just added an empty CT parameter set making it a template.
> ...

This should not be an issue any more.

http://d.puremagic.com/issues/show_bug.cgi?id=7511

On 04/16/2013 05:22 PM, Andrei Alexandrescu wrote:
> There's a discussion that may be of interest to the larger community:
> https://github.com/D-Programming-Language/dmd/pull/1877
>
> Andrei

I think inferring the return type and inferring the attributes are mostly orthogonal concerns. (and both are unrelated to the 'auto' storage class'.) But since there is precedent for conflating attribute inference with required function bodies, it might be fine.

In order not to be hit by Kenji's worst case debug output scenario, use something like the following:

void dw(T...)(T args)pure nothrow @trusted{
    debug try{writeln(args);}catch{assert(0);}
    else static assert(0);
}

On Tuesday, 16 April 2013 at 20:21:00 UTC, Peter Alexander wrote:
> This is the point I have a problem with:
>
>>> 2.2. One cannot opt out of nothrow or pure with auto functions.
>> This argument has one solid answer: don't use auto when the need is to specify an attribute pattern explicitly.
>
> I find this unacceptable. Thanks to the proliferation of template code in D, it is often rather difficult to spell out return types. Indeed, this is part of the original reason for auto's existence. Denying return type deduction for this use case is a major inconvenience.

How frequently do you write a non-templated function which returns a complex template type? It isn't something I really think about, but I'm pretty sure if I am returning a complex template type I've already got the function a template.

On Tuesday, 16 April 2013 at 15:22:56 UTC, Andrei Alexandrescu wrote:
> There's a discussion that may be of interest to the larger community: https://github.com/D-Programming-Language/dmd/pull/1877
>
> Andrei

Oh Yes, Yes, Yes, god Yes !
Yes, Yes, Yes !

Ho Yes !

On Tuesday, 16 April 2013 at 21:40:18 UTC, Timon Gehr wrote:
> I think inferring the return type and inferring the attributes are mostly orthogonal concerns. (and both are unrelated to the 'auto' storage class'.) But since there is precedent for conflating attribute inference with required function bodies, it might be fine.
>

auto is a storage class, so it should be possible to explicitly specify the return type :

auto ulong foo() { // Infered pure, nothrow and everything. Return type is ulong (would have been int if inferred).
    return 12;
}

On 4/16/2013 7:01 PM, deadalnix wrote:
> On Tuesday, 16 April 2013 at 15:22:56 UTC, Andrei Alexandrescu wrote:
>> There's a discussion that may be of interest to the larger community:
>> https://github.com/D-Programming-Language/dmd/pull/1877
>>
>> Andrei
>
> Oh Yes, Yes, Yes, god Yes !
> Yes, Yes, Yes !
>
> Ho Yes !

Not sure what you're saying yes to - the pro or the con?