www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Attribute inference for auto functions?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
There's a discussion that may be of interest to the larger community: 
https://github.com/D-Programming-Language/dmd/pull/1877

Andrei
Apr 16 2013
next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
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/
Apr 16 2013
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Apr 16 2013
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
This is the point I have a problem with:

 2.2. One cannot opt out of nothrow or pure with auto functions.

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.
Apr 16 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/16/13 4:20 PM, 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.

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.

Attribute inference is always done for templates. Andrei
Apr 17 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2013 8:07 AM, Andrei Alexandrescu wrote:
 On 4/16/13 4:20 PM, 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.

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.

Attribute inference is always done for templates.

And, I might add, I cannot recall a single adverse issue that has caused.
Apr 17 2013
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, April 17, 2013 12:35:07 Walter Bright wrote:
 On 4/17/2013 8:07 AM, Andrei Alexandrescu wrote:
 On 4/16/13 4:20 PM, 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.

Attribute inference is always done for templates.

And, I might add, I cannot recall a single adverse issue that has caused.

If anything, the fact that it doesn't infer more is the problem. The primary risk is if a particular set of template arguments previously resulted in the function being pure, nothrow, or safe but no longer do so after some code changes, and code using the template which requires pure, nothrow, or safe then no longer compiles. But odds are that that's the fault changes to the template arguments and not the template, and requiring explict attributes wouldn't fix the problem anyway, because then you're either stuck with a combinatorial explosion of template declarations or making it so that the template always has the same set of attributes and therefore only works with code that works with that exact set of attributes. Non-templated auto functions are not generally in the same boat, because their types are usually well-known, and therefore explicitly marking the attributes that you want works, but it may still be reasonable to do attribute inferrence for them. - Jonathan M Davis
Apr 22 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/17/13 3:58 AM, deadalnix wrote:
 Note that this is consistent with many choice D made.

 auto is a storage class. storage class usually stick to the function,
 not the return type :
 const Foo bar(); // Error as const qualify bar and not Foo.

 auto is about type inference. Attribute is part of the function type as
 much as it return type, and so it is expected that auto applied to a
 function infer its attributes and its return type.

 The problem you are talking about is very real, but much broader than
 this auto thing. The problem is that you have no control on what the
 storage classes bind on.

 Examples :
 extern(C) void function() foo; // does extern binds to foo, foo's type
 or both ?
 pure function() function() bar; // is bar a pure function ? is bar()
 pure ? Noth ? How to choose ?

 Back to the subject, if auto bind to the function it must infers
 attributes, if it binds to the return type, it mustn't. And right now,
 storage class bind to the function.

I think this is a solid argument. You may want to paste it in the github discussion for reference. Andrei
Apr 17 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/17/13 8:09 AM, Andrej Mitrovic wrote:
 On 4/17/13, Regan Heath<regan netmail.co.nz>  wrote:
 Solution:  You use 'auto' and compile the code producing a .di.  With the
 fix Andrei mentioned the .di has the full and complete function signature,
 without 'auto', including return type and all deduced attributes etc.

This doesn't work with voldemort types.

It's not supposed to; voldemort functions are by definition non-modular. Andrei
Apr 17 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2013 8:14 AM, Andrei Alexandrescu wrote:
 On 4/17/13 8:09 AM, Andrej Mitrovic wrote:
 On 4/17/13, Regan Heath<regan netmail.co.nz>  wrote:
 Solution:  You use 'auto' and compile the code producing a .di.  With the
 fix Andrei mentioned the .di has the full and complete function signature,
 without 'auto', including return type and all deduced attributes etc.

This doesn't work with voldemort types.

It's not supposed to; voldemort functions are by definition non-modular.

The whole point of voldemort functions is that you cannot name the return type, so there is no way to write a signature for it to put in the .di file. Hence, it not working with voldemort types is moot.
Apr 17 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2013 12:58 AM, deadalnix wrote:
 Back to the subject, if auto bind to the function it must infers attributes, if
 it binds to the return type, it mustn't. And right now, storage class bind to
 the function.

'auto', like all storage class annotations such as 'const', binds to the declaration and the declaration's type. It is perfectly consistent.
 extern(C) void function() foo; // does extern binds to foo, foo's type or both
?

foo is being declared, so it binds to foo.
 pure function() function() bar; // is bar a pure function ? is bar() pure ? 

bar is being declared, so it binds to bar.
Apr 17 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2013 6:28 PM, deadalnix wrote:
 Points raised in the thread show that people need in general to be able to
 annotate specifically the return type or whatever, and this is rather difficult
 with the current state of thing (and also it seems quite hard to fix).

To annotate the return type specifically with, say, const: const(T) foo(); And in fact const with parens works as a general type constructor: const(T)* foo(); // return mutable pointer to const T const without parens applies to the declaration.
Apr 17 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2013 10:35 AM, Jesse Phillips wrote:
 I don't think auto should be made specific to attribute inference. So I think
 the discussion should consider:

 const foo()//...

 would that be something that should also be a attribute inference.

Yes, the pull request does that, too.
Apr 17 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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
Apr 16 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
17-Apr-2013 01:13, Timon Gehr пишет:
 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

So it was a bug after all. Good to see it fixed. -- Dmitry Olshansky
Apr 17 2013
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+d gmail.com> writes:
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.

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.
Apr 16 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Wednesday, 17 April 2013 at 01:55:54 UTC, Jesse Phillips wrote:
 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.

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.

Often enough. I often find myself returning ranges, which are almost invariably complex template types. And, to be honest, I would just like to use auto without being locked into inferred attributes. It just feels wrong that these things should be conflated, and I get the feeling we will regret this later on when D starts to be used in larger projects.
Apr 17 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 17 April 2013 at 07:04:16 UTC, Peter Alexander 
wrote:
 Often enough. I often find myself returning ranges, which are 
 almost invariably complex template types.

 And, to be honest, I would just like to use auto without being 
 locked into inferred attributes. It just feels wrong that these 
 things should be conflated, and I get the feeling we will 
 regret this later on when D starts to be used in larger 
 projects.

Note that this is consistent with many choice D made. auto is a storage class. storage class usually stick to the function, not the return type : const Foo bar(); // Error as const qualify bar and not Foo. auto is about type inference. Attribute is part of the function type as much as it return type, and so it is expected that auto applied to a function infer its attributes and its return type. The problem you are talking about is very real, but much broader than this auto thing. The problem is that you have no control on what the storage classes bind on. Examples : extern(C) void function() foo; // does extern binds to foo, foo's type or both ? pure function() function() bar; // is bar a pure function ? is bar() pure ? Noth ? How to choose ? Back to the subject, if auto bind to the function it must infers attributes, if it binds to the return type, it mustn't. And right now, storage class bind to the function.
Apr 17 2013
prev sibling next sibling parent "qznc" <qznc go.to> writes:
On Wednesday, 17 April 2013 at 07:04:16 UTC, Peter Alexander 
wrote:
 On Wednesday, 17 April 2013 at 01:55:54 UTC, Jesse Phillips 
 wrote:
 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.

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.

Often enough. I often find myself returning ranges, which are almost invariably complex template types. And, to be honest, I would just like to use auto without being locked into inferred attributes. It just feels wrong that these things should be conflated, and I get the feeling we will regret this later on when D starts to be used in larger projects.

I strongly believe you should never use "auto" for API types, because it is too easy to break them. If Dont-Repeat-Yourself/complex types is a problem, they should be solved at the other end by enhancing function body type inference. An alternative approach would be to do this optimization during optimization. However, this means it has to be reimplemented in dmd, LLVM, GCC separately. This is e.g. the case for pure-inference in C code.
Apr 17 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/17/13, Jesse Phillips <Jessekphillips+d gmail.com> wrote:
 How frequently do you write a non-templated function which
 returns a complex template type?

This can be common if the function is a member function that returns some kind of a range on internal data, for example: import std.range; struct S { int[] arr; auto range() { return cycle(arr).stride(2); } } There's no need to make "range" a template here, but specifying the return type isn't always possible or easy to do.
Apr 17 2013
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Tue, 16 Apr 2013 21:20:59 +0100, Peter Alexander  
<peter.alexander.au gmail.com> wrote:

 This is the point I have a problem with:

 2.2. One cannot opt out of nothrow or pure with auto functions.

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.

Solution: You use 'auto' and compile the code producing a .di. With the fix Andrei mentioned the .di has the full and complete function signature, without 'auto', including return type and all deduced attributes etc. You alter the signature to suit and copy it back to the .d file. This is how it should be done, IMO, because now you've explicitly defined your library interface so when you accidentally change/break it by modifying the code in the library function body, the compiler will immediately tell you. It's win-win or so it seems to me.
 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.

I can't see how it can be any other way. An interface needs to be clearly defined or it's consumer can't use it. 'auto' does not suit that purpose at all, currently, and this doesn't change with this pull. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Apr 17 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/17/13, Regan Heath <regan netmail.co.nz> wrote:
 Solution:  You use 'auto' and compile the code producing a .di.  With the
 fix Andrei mentioned the .di has the full and complete function signature,
 without 'auto', including return type and all deduced attributes etc.

This doesn't work with voldemort types.
Apr 17 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Wednesday, 17 April 2013 at 07:58:42 UTC, deadalnix wrote:
 auto is about type inference. Attribute is part of the function 
 type as much as it return type, and so it is expected that auto 
 applied to a function infer its attributes and its return type.

I disagree. Attributes are completely separate from return value, and I do not think it is "expected" that auto should infer attributes.
 The problem you are talking about is very real, but much 
 broader than this auto thing. The problem is that you have no 
 control on what the storage classes bind on.

 Examples :
 extern(C) void function() foo; // does extern binds to foo, 
 foo's type or both ?
 pure function() function() bar; // is bar a pure function ? is 
 bar() pure ? Noth ? How to choose ?

Yes, that is a problem, but not related to this change.
 Back to the subject, if auto bind to the function it must 
 infers attributes, if it binds to the return type, it mustn't. 
 And right now, storage class bind to the function.

I think you are confusing separate things here. First, 'auto' is a storage class that means 'no other storage class'. It does NOT mean type inference. You do not need to use 'auto' to get type inference. You cannot use 'auto' in conjunction with other storage classes to get type inference. auto foo(); // type inference const foo(); // type inference auto const foo(); // illegal, two storage classes As you can see, auto is neither sufficient, nor required for type inference. The storage class you use has absolutely nothing to do with type inference. Type inference happens if and only if you do not specify a return type. Storage class and type inference are 100% orthogonal. With that matter cleared up, your argument no longer holds water. It doesn't matter what 'auto' binds to because 'auto' has nothing to do with return type inference, and shouldn't affect attribute inference either. The name of this thread is quite misleading. The proposal also has nothing to do with auto. The proposal is to infer attributes when the return type is inferred. I think it's worth being clear on that otherwise people will confuse storage classes with type/attribute inference.
Apr 17 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/17/13, Peter Alexander <peter.alexander.au gmail.com> wrote:
 Type inference happens if and only if you do
 not specify a return type.

That's not true, you still need to use auto. This function definition is illegal: x() { return 1; } As for being able to use 'const' for type inference it's completely an implementation issue. It's not by design at all. You can even substitute 'auto' for meaningless crap like this in module scope: static x() { return 1; } If return type inference is wanted then 'auto' should be required at all times. What's the point in writing obfuscated code like the above?
Apr 17 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/17/13, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 As for being able to use 'const' for type inference it's completely an
 implementation issue. It's not by design at all.

Actually I'm wrong about this now that I've re-read the spec. You can use another storage class instead of auto (strangely I don't remember this being discussed in TDPL though). However there are too many things in DMD which are "storage classes", when they shouldn't be. E.g. property.
Apr 17 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Wednesday, 17 April 2013 at 12:46:53 UTC, Andrej Mitrovic 
wrote:
 On 4/17/13, Peter Alexander <peter.alexander.au gmail.com> 
 wrote:
 Type inference happens if and only if you do
 not specify a return type.

That's not true, you still need to use auto. This function definition is illegal: x() { return 1; }

You don't need to use auto. Any storage class will do.
 As for being able to use 'const' for type inference it's 
 completely an
 implementation issue. It's not by design at all. You can even
 substitute 'auto' for meaningless crap like this in module 
 scope:

 static x() { return 1; }

 If return type inference is wanted then 'auto' should be 
 required at
 all times. What's the point in writing obfuscated code like the 
 above?

Because it's required? This is illegal: auto const foo(); If you want type inference then you just need to use: const foo(); And yes, it is by design. The spec is quite clear on this issue. Type inference is signalled by lack of return type -- not the presence of auto. auto is only required when no other storage class is wanted, to make the parser happy. auto is nothing whatsoever to do with type inference.
Apr 17 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Wednesday, 17 April 2013 at 12:49:41 UTC, Andrej Mitrovic
wrote:
 On 4/17/13, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 As for being able to use 'const' for type inference it's 
 completely an
 implementation issue. It's not by design at all.

Actually I'm wrong about this now that I've re-read the spec. You can use another storage class instead of auto (strangely I don't remember this being discussed in TDPL though). However there are too many things in DMD which are "storage classes", when they shouldn't be. E.g. property.

Sorry, just saw this. Ignore previous reply.
Apr 17 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Wednesday, 17 April 2013 at 13:59:05 UTC, Peter Alexander 
wrote:
[...]
 If you want type inference then you just need to use:

 const foo();

 And yes, it is by design. The spec is quite clear on this 
 issue. Type inference is signalled by lack of return type -- 
 not the presence of auto. auto is only required when no other 
 storage class is wanted, to make the parser happy. auto is 
 nothing whatsoever to do with type inference.

I think you've made some good clarification points. auto is used only when there is no other storage class, and "storage class" is a somewhat misleading term because some storage class's seem to have nothing to do with "storage". The point you made, is that what is being proposed is if or if not D should be extended to perform attribute inference along with type inference. The auto keyword is only required when no other storage class is specified, so it really means that attribute inference will be done all the time unless you specifically specify the attributes. Is this the case? --rt
Apr 17 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 17 April 2013 at 12:22:21 UTC, Peter Alexander 
wrote:
 On Wednesday, 17 April 2013 at 07:58:42 UTC, deadalnix wrote:
 auto is about type inference. Attribute is part of the 
 function type as much as it return type, and so it is expected 
 that auto applied to a function infer its attributes and its 
 return type.

I disagree. Attributes are completely separate from return value, and I do not think it is "expected" that auto should infer attributes.

auto is generally understood as type inference, so ti isn't an heresy.
 The problem you are talking about is very real, but much 
 broader than this auto thing. The problem is that you have no 
 control on what the storage classes bind on.

 Examples :
 extern(C) void function() foo; // does extern binds to foo, 
 foo's type or both ?
 pure function() function() bar; // is bar a pure function ? is 
 bar() pure ? Noth ? How to choose ?

Yes, that is a problem, but not related to this change.

It is, because you can't express both "I want return type inference" and " want full type inference"
 Back to the subject, if auto bind to the function it must 
 infers attributes, if it binds to the return type, it mustn't. 
 And right now, storage class bind to the function.

I think you are confusing separate things here. First, 'auto' is a storage class that means 'no other storage class'. It does NOT mean type inference. You do not need to use 'auto' to get type inference. You cannot use 'auto' in conjunction with other storage classes to get type inference. auto foo(); // type inference const foo(); // type inference auto const foo(); // illegal, two storage classes As you can see, auto is neither sufficient, nor required for type inference. The storage class you use has absolutely nothing to do with type inference. Type inference happens if and only if you do not specify a return type. Storage class and type inference are 100% orthogonal.

It is sufficient. It is true that it isn't required as absence of type + one storage class means type inference. I kind of oversimplyfied that part. The intent of auto is still type inference, as this is a storage class that mean nothing, except that it allow to omit the type.
 The name of this thread is quite misleading. The proposal also 
 has nothing to do with auto. The proposal is to infer 
 attributes when the return type is inferred. I think it's worth 
 being clear on that otherwise people will confuse storage 
 classes with type/attribute inference.

What storage class stand for is already a blurry topic. I don't think any confusion can be added.
Apr 17 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Wednesday, 17 April 2013 at 16:10:02 UTC, deadalnix wrote:
 On Wednesday, 17 April 2013 at 12:22:21 UTC, Peter Alexander 
 wrote:
 On Wednesday, 17 April 2013 at 07:58:42 UTC, deadalnix wrote:
 auto is about type inference. Attribute is part of the 
 function type as much as it return type, and so it is 
 expected that auto applied to a function infer its attributes 
 and its return type.

I disagree. Attributes are completely separate from return value, and I do not think it is "expected" that auto should infer attributes.

auto is generally understood as type inference, so ti isn't an heresy.
 The problem you are talking about is very real, but much 
 broader than this auto thing. The problem is that you have no 
 control on what the storage classes bind on.

 Examples :
 extern(C) void function() foo; // does extern binds to foo, 
 foo's type or both ?
 pure function() function() bar; // is bar a pure function ? 
 is bar() pure ? Noth ? How to choose ?

Yes, that is a problem, but not related to this change.

It is, because you can't express both "I want return type inference" and " want full type inference"
 Back to the subject, if auto bind to the function it must 
 infers attributes, if it binds to the return type, it 
 mustn't. And right now, storage class bind to the function.

I think you are confusing separate things here. First, 'auto' is a storage class that means 'no other storage class'. It does NOT mean type inference. You do not need to use 'auto' to get type inference. You cannot use 'auto' in conjunction with other storage classes to get type inference. auto foo(); // type inference const foo(); // type inference auto const foo(); // illegal, two storage classes As you can see, auto is neither sufficient, nor required for type inference. The storage class you use has absolutely nothing to do with type inference. Type inference happens if and only if you do not specify a return type. Storage class and type inference are 100% orthogonal.

It is sufficient. It is true that it isn't required as absence of type + one storage class means type inference. I kind of oversimplyfied that part. The intent of auto is still type inference, as this is a storage class that mean nothing, except that it allow to omit the type.
 The name of this thread is quite misleading. The proposal also 
 has nothing to do with auto. The proposal is to infer 
 attributes when the return type is inferred. I think it's 
 worth being clear on that otherwise people will confuse 
 storage classes with type/attribute inference.

What storage class stand for is already a blurry topic. I don't think any confusion can be added.

It's certainly not helpful if we keep on blurring the concepts. The "auto" keyword currently means nothing except that when no other storage class is present you can specify it to allow the compiler to proceed without error, otherwise type inference is always performed unless inference is overridden with an explicit type. The proposal therefore seems to be about extending D to always perform attribute inference along with type inference unless the attributes are explicitly specified. The question I have is if the proposal wants to extend the meaning of the "auto' keyword so that it will be required in order for attribute inference to take place, but that indeed does confuse things because we're using the same keyword for two completely two different purposes, and it clashes with the use of auto in some cases. -rt
Apr 17 2013
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Wednesday, 17 April 2013 at 16:26:30 UTC, Rob T wrote:
 The proposal therefore seems to be about extending D to always 
 perform attribute inference along with type inference unless 
 the attributes are explicitly specified.

 The question I have is if the proposal wants to extend the 
 meaning of the "auto' keyword so that it will be required in 
 order for attribute inference to take place, but that indeed 
 does confuse things because we're using the same keyword for 
 two completely two different purposes, and it clashes with the 
 use of auto in some cases.

 -rt

This is a very good description of the change. I don't think auto should be made specific to attribute inference. So I think the discussion should consider: const foo()//... would that be something that should also be a attribute inference. I think I'm still ok with that as it is still requesting inference. Note that you can not specify an inferred const return type. That is this makes a the function const (not valid as a free form function), and not the return type.
Apr 17 2013
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Wednesday, 17 April 2013 at 07:04:16 UTC, Peter Alexander 
wrote:
 Often enough. I often find myself returning ranges, which are 
 almost invariably complex template types.

Hmm, I'm still trying to decide if this is a major concern. Generally when returning a range, this is done because operations are being performed on a container, the specific container isn't important and many times nor is the type in the container. This means my function is a template. The times when I could see returning a complex type where the function isn't templates is when I'm loading the data to be consumed. In this case I generally will return the container itself (since ownership isn't with the called function).
Apr 17 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 17 April 2013 at 08:39:37 UTC, qznc wrote:
 An alternative approach would be to do this optimization during 
 optimization. However, this means it has to be reimplemented in 
 dmd, LLVM, GCC separately. This is e.g. the case for 
 pure-inference in C code.

LDC/LLVM does something very similar already (on the IR level), but obviously not across multiple compilation units, as the function body has to be available to the optimizer. David
Apr 17 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 17 April 2013 at 19:53:07 UTC, Walter Bright wrote:
 On 4/17/2013 12:58 AM, deadalnix wrote:
 Back to the subject, if auto bind to the function it must 
 infers attributes, if
 it binds to the return type, it mustn't. And right now, 
 storage class bind to
 the function.

'auto', like all storage class annotations such as 'const', binds to the declaration and the declaration's type. It is perfectly consistent.
 extern(C) void function() foo; // does extern binds to foo,

foo is being declared, so it binds to foo.
 pure function() function() bar; // is bar a pure function ?

bar is being declared, so it binds to bar.

Yes I know. That was my point : auto bind to the function according to current spec, so function type should be inferred, which imply both return type and attributes. Points raised in the thread show that people need in general to be able to annotate specifically the return type or whatever, and this is rather difficult with the current state of thing (and also it seems quite hard to fix).
Apr 17 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 18 April 2013 at 01:52:10 UTC, Walter Bright wrote:
 To annotate the return type specifically with, say, const:

     const(T) foo();

 And in fact const with parens works as a general type 
 constructor:

     const(T)* foo();  // return mutable pointer to const T

 const without parens applies to the declaration.

This doesn't work with many attributes.
Apr 17 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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); }
Apr 16 2013
parent "deadalnix" <deadalnix gmail.com> writes:
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; }
Apr 16 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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 !
Apr 16 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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?
Apr 16 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/16/2013 7:30 PM, deadalnix wrote:
 I agree with you, I know it may
 sound hard to believe, but it had to happen one day :D

I'll mark it on my calendar! BTW, I think we can do attribute inference for all private functions, too.
Apr 16 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/16/2013 10:31 PM, deadalnix wrote:
 On Wednesday, 17 April 2013 at 04:44:59 UTC, Walter Bright wrote:
 BTW, I think we can do attribute inference for all private functions, too.

Don't this risk to conflict with LTO ?

How so?
Apr 16 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 17 April 2013 at 02:22:31 UTC, Walter Bright wrote:
 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?

Yes to the pull request, yes to the inference. I agree with you, I know it may sound hard to believe, but it had to happen one day :D
Apr 16 2013
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+d gmail.com> writes:
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

I'm not convinced that specifying the exact return type is such a huge inconvenience to those who use separate compilation. I don't view this as an inconsistency, but definitely a change to why one might choose to use auto. I'm pretty much for this change. However, I also think it would be good to introduce attributes to specify a throwing function as it would have uses in a file headed with nothrow: I'd suggest the same for pure, but 'nopure' isn't the greatest of names. Anyway it is the same reason we have system, I'd just hope they don't get added as throws and nopure as that would be inconsistent.
Apr 16 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 17 April 2013 at 04:44:59 UTC, Walter Bright wrote:
 On 4/16/2013 7:30 PM, deadalnix wrote:
 I agree with you, I know it may
 sound hard to believe, but it had to happen one day :D

I'll mark it on my calendar! BTW, I think we can do attribute inference for all private functions, too.

Don't this risk to conflict with LTO ?
Apr 16 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 17 April 2013 at 05:55:07 UTC, Walter Bright wrote:
 On 4/16/2013 10:31 PM, deadalnix wrote:
 On Wednesday, 17 April 2013 at 04:44:59 UTC, Walter Bright 
 wrote:
 BTW, I think we can do attribute inference for all private 
 functions, too.

Don't this risk to conflict with LTO ?

How so?

Never mind, I think I was wrong. It is a good idea.
Apr 16 2013
prev sibling next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 16.04.2013 17:22, Andrei Alexandrescu pisze:
 There's a discussion that may be of interest to the larger community:
 https://github.com/D-Programming-Language/dmd/pull/1877

On demand inference FTW! void fn() auto { ... } auto fn() auto { ... }
Apr 17 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-04-17 10:31, Piotr Szturmaj wrote:

 On demand inference FTW!

 void fn() auto {
      ...
 }

 auto fn() auto {
      ...
 }

Double auto, hehe. -- /Jacob Carlborg
Apr 17 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/17/13 4:31 AM, Piotr Szturmaj wrote:
 W dniu 16.04.2013 17:22, Andrei Alexandrescu pisze:
 There's a discussion that may be of interest to the larger community:
 https://github.com/D-Programming-Language/dmd/pull/1877

On demand inference FTW! void fn() auto { ... } auto fn() auto { ... }

I think this is a bit much. Simplicity is a good commodity to allow oneself of, and absorbing two different meanings of 'auto' in the same construct is not simple. Andrei
Apr 17 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2013 8:12 AM, Andrei Alexandrescu wrote:
 I think this is a bit much. Simplicity is a good commodity to allow oneself of,
 and absorbing two different meanings of 'auto' in the same construct is not
simple.

It also goes back to your discussion of the observation that programmers do not go back and annotate the code, even for large benefits.
Apr 17 2013
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-04-16 15:22:56 +0000, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

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

I agree attribute inference is needed. I don't think 'auto' is a suitable trigger. It'll encourage people to replace the return type on existing and new functions (making things more obscure) as a way get attribute inference. Instead, all functions should have the benefit of attribute inference. I'd rather have a marker to prevent it when needed than have to opt it. For instance, if providing a stable API for a library is a concern, put that marker on those exported functions. Perhaps "export" could be that marker. Unfortunately, that'll be slow. DMD will have to reprocess the function body for every called function transitively each time it compiles. The solution for that is to use .di files as a cache: in the process of creating a .di file the inferred attributes could be made explicit. Then disallow attribute inference for functions parsed from a .di file (so you can still provide a body for inlining). All this might pose a tricky cache-invalidation problem however: when a function somewhere changes you need to purge all the dependent di files *before* recompiling anything. :-/ Compilation speed is not a problem for functions with the "auto" return type because there are only a few of them. At least that's how it is right now. Allowing attribute inference only for this category of function might change those statistics after a few months in the wild, and then you'll have the compilation performance problems described above. Which might not be a bad thing, as then you'll need to overhaul the compilation model to fix this, and then you'll be able to enable it for all functions. ;-) -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Apr 17 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2013 10:37 AM, Michel Fortin wrote:
 Compilation speed is not a problem for functions with the "auto" return type
 because there are only a few of them.

It is not a problem right now because the compiler has to semantically analyze their function bodies already in order to determine the return type. It is insignificant to additionally gather the attribute information.
Apr 17 2013
parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-04-17 19:05:01 +0000, Walter Bright <newshound2 digitalmars.com> said:

 On 4/17/2013 10:37 AM, Michel Fortin wrote:
 Compilation speed is not a problem for functions with the "auto" return type
 because there are only a few of them.

It is not a problem right now because the compiler has to semantically analyze their function bodies already in order to determine the return type. It is insignificant to additionally gather the attribute information.

True, but beside the point. My point was that if auto allows attribute inference people will be tempted to (and will do) change their return types to auto in their programs just to get that benefit (no one wants to annotate all their functions). Thus, as more and more functions become "auto" compile times will become slower. Pushed to the extreme, you'd get the same result as if you were inferring attributes for all functions, plus more confusion because all the return types are obfuscated. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Apr 17 2013
prev sibling next sibling parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
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

I wish to bring Someboddies consern to this form. What does attribute inference mean for inheritance? Do all derived classes need to be known for inference to take place? Not having the ability to claim a base function can be overridden with a throwing function could cause some issue... Hmm but we can still specify the type so I guess it still isn't a major, but I could see auto being used more causing a library writer to make restrictions on their function because what they write is applicable but not really considering derived classes could reasonably throw.
Apr 17 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2013 10:41 AM, Jesse Phillips wrote:
 I wish to bring Someboddies consern to this form.

 What does attribute inference mean for inheritance?

I specifically addressed his concern in the git page: "This is the same issue as defining a function with 'auto' in one place and referring to it having a specific type/attribute in another. So I think all the same arguments and reasoning discussed above apply equally."
Apr 17 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2013 12:06 PM, Walter Bright wrote:
 On 4/17/2013 10:41 AM, Jesse Phillips wrote:
 I wish to bring Someboddies consern to this form.

 What does attribute inference mean for inheritance?

I specifically addressed his concern in the git page: "This is the same issue as defining a function with 'auto' in one place and referring to it having a specific type/attribute in another. So I think all the same arguments and reasoning discussed above apply equally."

His followup doesn't change that. It's still the same issue (covariance) which is discussed repeatedly.
Apr 17 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
  Th
On 04/17/2013 09:06 PM, Walter Bright wrote:
 On 4/17/2013 10:41 AM, Jesse Phillips wrote:
 I wish to bring Someboddies consern to this form.

 What does attribute inference mean for inheritance?

I specifically addressed his concern in the git page: "This is the same issue as defining a function with 'auto' in one place and referring to it having a specific type/attribute in another. So I think all the same arguments and reasoning discussed above apply equally."

Why is this a valid form of reasoning? The signature of a function that has its return type inferred includes the function body. Furthermore, it is not the same issue. It is the dual issue. The distinction is very relevant because pure and nothrow are designed in an asymmetric way, given inference. Attributes can force the specification in one direction only (provide more guarantees to callers), but not in the other one (require less from subclasses). The concerns the latter can certainly not be dismissed by using the same arguments and reasoning as for the former without any further examination.
Apr 17 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2013 3:20 PM, Timon Gehr wrote:
 "This is the same issue as defining a function with 'auto' in one place
 and referring to it having a specific type/attribute in another. So I
 think all the same arguments and reasoning discussed above apply equally."

Why is this a valid form of reasoning? The signature of a function that has its return type inferred includes the function body. Furthermore, it is not the same issue. It is the dual issue. The distinction is very relevant because pure and nothrow are designed in an asymmetric way,

They are the same - adding the attribute retains covariance.
 given
 inference. Attributes can force the specification in one direction only
(provide
 more guarantees to callers), but not in the other one (require less from
 subclasses).

Pure and nothrow provide more guarantees, hence covariance.
 The concerns the latter can certainly not be dismissed by using the same
 arguments and reasoning as for the former without any further examination.

They're both the same issue of covariance.
Apr 17 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2013 6:32 PM, deadalnix wrote:
 No : if a super function suddenly become pure because its implementation
 changed, then all kind of subclasses can broke. Generally, it is a bad idea for
 a super class to be aware of its subclasses.

Yet this is the same issue as auto for other functions.
 But defining a function that is going to be overridden as auto is asking for
 trouble in the first place.

Of course.
Apr 17 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/18/2013 01:46 AM, Walter Bright wrote:
 On 4/17/2013 3:20 PM, Timon Gehr wrote:
 "This is the same issue as defining a function with 'auto' in one place
 and referring to it having a specific type/attribute in another. So I
 think all the same arguments and reasoning discussed above apply
 equally."

Why is this a valid form of reasoning? The signature of a function that has its return type inferred includes the function body. Furthermore, it is not the same issue. It is the dual issue. The distinction is very relevant because pure and nothrow are designed in an asymmetric way,

They are the same

No. In one case you infer guarantees only. (those restrict what can be done in the future without potentially breaking code, but that's it.) In the other case you infer restrictions too, in an unsound way because the inference does not take into consideration the subclasses.
 - adding the attribute retains covariance.

I am sorry, but I do not understand your notion of covariance. Covariance is a precise notion from category theory. (A mapping between categories that conserves morphisms is called a covariant functor.)
 given
 inference. Attributes can force the specification in one direction
 only (provide
 more guarantees to callers), but not in the other one (require less from
 subclasses).

Pure and nothrow provide more guarantees, hence covariance.
 The concerns the latter can certainly not be dismissed by using the same
 arguments and reasoning as for the former without any further
 examination.

They're both the same issue of covariance.

class C{ final foo(){ ... } // <- this signature is foo's signature only auto bar(){ ... } // <- this signature has to fit all overrides } In the first case, inference is mostly fine because you cannot unduly restrict someone: The signature will actually match foo's implementation. In the second case you cannot infer the attributes because you do not know all subclasses. The signature will potentially not match all overrides. Case in point, I just noticed the following regression on git head: import std.stdio; class C(T){ T foo(){ return 2; } } class D : C!int{ override int foo(){ writeln(super.foo()); return 3; } // error } Inference shouldn't be done for virtual functions. http://d.puremagic.com/issues/show_bug.cgi?id=9952
Apr 17 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2013 11:49 PM, Timon Gehr wrote:
 I am sorry, but I do not understand your notion of covariance.

Overriding functions can add pure or nothrow and remain covariant.
 In the second case you cannot infer the attributes because you do not know all
 subclasses. The signature will potentially not match all overrides.

If you want a precise signature, don't use auto. It's the same case as everywhere else.
 Case in point, I just noticed the following regression on git head:

 import std.stdio;

 class C(T){
      T foo(){ return 2; }
 }

 class D : C!int{
      override int foo(){ writeln(super.foo()); return 3; } // error
 }


 Inference shouldn't be done for virtual functions.

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

This is not an auto issue.
Apr 18 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/18/13 2:49 AM, Timon Gehr wrote:
 On 04/18/2013 01:46 AM, Walter Bright wrote:
 - adding the attribute retains covariance.

I am sorry, but I do not understand your notion of covariance.

I think he means subtyping. An attributed function (pure, nothrow) is a subtype of a non-attributed function. That means it can substitute the non-attributed function. Andrei
Apr 18 2013
prev sibling next sibling parent "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
Yes, please do attribute inference!
Apr 17 2013
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Wednesday, 17 April 2013 at 19:06:42 UTC, Walter Bright wrote:
 On 4/17/2013 10:41 AM, Jesse Phillips wrote:
 I wish to bring Someboddies consern to this form.

 What does attribute inference mean for inheritance?

I specifically addressed his concern in the git page: "This is the same issue as defining a function with 'auto' in one place and referring to it having a specific type/attribute in another. So I think all the same arguments and reasoning discussed above apply equally."

Initially I thought you were replying to something further up in the thread as it seemed more applicable to something I read before, and I did feel the issue of inheritance was different. But I think you are correct, it is the same issue.
Apr 17 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 17 April 2013 at 23:46:08 UTC, Walter Bright wrote:
 On 4/17/2013 3:20 PM, Timon Gehr wrote:
 "This is the same issue as defining a function with 'auto' in 
 one place
 and referring to it having a specific type/attribute in 
 another. So I
 think all the same arguments and reasoning discussed above 
 apply equally."

Why is this a valid form of reasoning? The signature of a function that has its return type inferred includes the function body. Furthermore, it is not the same issue. It is the dual issue. The distinction is very relevant because pure and nothrow are designed in an asymmetric way,

They are the same - adding the attribute retains covariance.

No : if a super function suddenly become pure because its implementation changed, then all kind of subclasses can broke. Generally, it is a bad idea for a super class to be aware of its subclasses. But defining a function that is going to be overridden as auto is asking for trouble in the first place.
Apr 17 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/16/2013 8:22 AM, 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

What do you think of this: typeof(return) foo(int x) { return x; } ? That would only infer the return type, not the attributes.
Apr 17 2013
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 18 April 2013 at 02:40:42 UTC, Walter Bright wrote:
 On 4/16/2013 8:22 AM, 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

What do you think of this: typeof(return) foo(int x) { return x; } ? That would only infer the return type, not the attributes.

Very nice !
Apr 17 2013
prev sibling next sibling parent reply "Zach the Mystic" <reachzach gggggmail.com> writes:
On Thursday, 18 April 2013 at 02:40:42 UTC, Walter Bright wrote:
 On 4/16/2013 8:22 AM, 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

What do you think of this: typeof(return) foo(int x) { return x; } ? That would only infer the return type, not the attributes.

I don't actually have an opinion on whether attributes should be inferred, but ' auto' (as opposed to ' infer') would be a relatively innocuous way to do it explicitly instead of implicitly.
Apr 17 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2013 7:50 PM, Zach the Mystic wrote:
 On Thursday, 18 April 2013 at 02:40:42 UTC, Walter Bright wrote:
 On 4/16/2013 8:22 AM, 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

What do you think of this: typeof(return) foo(int x) { return x; } ? That would only infer the return type, not the attributes.

I don't actually have an opinion on whether attributes should be inferred, but ' auto' (as opposed to ' infer') would be a relatively innocuous way to do it explicitly instead of implicitly.

Except that we already support typeof(return) inside of a function.
Apr 17 2013
prev sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 18.04.2013 04:50, Zach the Mystic pisze:
 On Thursday, 18 April 2013 at 02:40:42 UTC, Walter Bright wrote:
 On 4/16/2013 8:22 AM, 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

What do you think of this: typeof(return) foo(int x) { return x; } ? That would only infer the return type, not the attributes.

I don't actually have an opinion on whether attributes should be inferred, but ' auto' (as opposed to ' infer') would be a relatively innocuous way to do it explicitly instead of implicitly.

And this can apply to whole scopes.
Apr 17 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Thursday, 18 April 2013 at 03:19:38 UTC, Walter Bright wrote:
 On 4/17/2013 7:50 PM, Zach the Mystic wrote:
 On Thursday, 18 April 2013 at 02:40:42 UTC, Walter Bright 
 wrote:
 On 4/16/2013 8:22 AM, 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

What do you think of this: typeof(return) foo(int x) { return x; } ? That would only infer the return type, not the attributes.

I don't actually have an opinion on whether attributes should be inferred, but ' auto' (as opposed to ' infer') would be a relatively innocuous way to do it explicitly instead of implicitly.

Except that we already support typeof(return) inside of a function.

Yeah, I basically agree. If I had to choose right now, typeof(return) makes more sense. It relies on the assumption that most of the time when you want to 'auto' the return type, you also are okay with autoing the attributes (hence typeof(return) will be much rarer than 'auto'). It seems like a pretty safe assumption to make. And it's weird but ' ' is just uglier than things without ' ', despite that it would be nice for UDAs and other attributes if that weren't the case.
Apr 17 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Thursday, 18 April 2013 at 03:42:50 UTC, Piotr Szturmaj wrote:
 W dniu 18.04.2013 04:50, Zach the Mystic pisze:
 On Thursday, 18 April 2013 at 02:40:42 UTC, Walter Bright 
 wrote:
 On 4/16/2013 8:22 AM, 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

What do you think of this: typeof(return) foo(int x) { return x; } ? That would only infer the return type, not the attributes.

I don't actually have an opinion on whether attributes should be inferred, but ' auto' (as opposed to ' infer') would be a relatively innocuous way to do it explicitly instead of implicitly.

And this can apply to whole scopes.

Yeah, that's true... 'typeof(return):' would not look good at the top of a file. I feel like this feature is attempting to turn on a vacuum, seeing how many explicit things can be sucked into the implicit vortex. I think the gold medal would be if there were a way to do everything implicitly, but some things may resist being sucked in, and for good reason. The syntax ' auto' seems like a bronze medal solution, so I'd be glad to see it lose to something better.
Apr 17 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 18 April 2013 at 05:59:20 UTC, kenji hara wrote:
 It will break existing code.

 int foo() {
     typeof(return) bar() { return 1; }
     return bar();
 }

 typeof(return) represents the return type of foo, that is int.

That is true :( Don't seem fixable.
Apr 17 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2013 11:34 PM, deadalnix wrote:
 On Thursday, 18 April 2013 at 05:59:20 UTC, kenji hara wrote:
 It will break existing code.

 int foo() {
     typeof(return) bar() { return 1; }
     return bar();
 }

 typeof(return) represents the return type of foo, that is int.

That is true :( Don't seem fixable.

It is fixable if it is special cased, but special cases stink.
Apr 17 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/18/13 2:38 AM, Walter Bright wrote:
 On 4/17/2013 11:34 PM, deadalnix wrote:
 On Thursday, 18 April 2013 at 05:59:20 UTC, kenji hara wrote:
 It will break existing code.

 int foo() {
 typeof(return) bar() { return 1; }
 return bar();
 }

 typeof(return) represents the return type of foo, that is int.

That is true :( Don't seem fixable.

It is fixable if it is special cased, but special cases stink.

Thanks Kenji for a surgical destruction. Andrei
Apr 18 2013
parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 18.04.2013 16:58, Andrei Alexandrescu pisze:
 On 4/18/13 2:38 AM, Walter Bright wrote:
 On 4/17/2013 11:34 PM, deadalnix wrote:
 On Thursday, 18 April 2013 at 05:59:20 UTC, kenji hara wrote:
 It will break existing code.

 int foo() {
 typeof(return) bar() { return 1; }
 return bar();
 }

 typeof(return) represents the return type of foo, that is int.

That is true :( Don't seem fixable.

It is fixable if it is special cased, but special cases stink.

Thanks Kenji for a surgical destruction.

What about this: auto inferReturnTypeAndAttributes() { ... } auto(return) inferOnlyReturnType() { ... } or since all attributes are constraints, it can be rewritten to: auto inferOnlyReturnType() pure nothrow safe { ... } It really doesn't make sense to infer impurity, throwing or unsafety because these are the default. I imagine there are some use cases where programmer for example wants to infer all but purity, possibly because some other part of the code relies on pure behavior of his function, and he doesn't care about the other attributes. Example of pure function where nothrow and safety are inferred: auto inferAllButPurity() pure { ... } To sum up: 1. auto - infers all 2. auto(return) - infers only a return type 3. auto fn() attrs... - infers return type and all not specified attributes Second and third are equivalent, thus auto(return) is optional. There were some voices about breaking overriden functions by adding/inferring superclass function attribute. I think this is an oversight, virtual functions should not have attributes inferred.
Apr 19 2013
next sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 19.04.2013 15:43, John Colvin pisze:
 I like this. It provides a good balance of control and automation.

 how would template functions be treated with auto(return)?

I see no need for special treating of template functions. In this case only return type would be inferred. Programmers should then specify attributes explicitly. By default, template functions with auto(return) would be impure, throwing and unsafe.
Apr 19 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/19/2013 6:55 AM, deadalnix wrote:
 As of for 2 I'd rather have a standard way to have attribute binding to the
 return type or the declaration. This is a recurring problem, and auto is simply
 one instance of it.

I'm not understanding it being a recurring problem. There is a recurring misunderstanding that attributes are applying to a type when they are defined as applying to the declaration.
 auto applied to the return type means that we infers the return type, applied
to
 the function it means infers return type AND attributes.

auto never applies to a type, it always applies to the declaration and hence the type of that declaration.
Apr 19 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/19/2013 09:34 PM, deadalnix wrote:
 On Friday, 19 April 2013 at 19:06:39 UTC, Walter Bright wrote:
 On 4/19/2013 6:55 AM, deadalnix wrote:
 As of for 2 I'd rather have a standard way to have attribute binding
 to the
 return type or the declaration. This is a recurring problem, and auto
 is simply
 one instance of it.

I'm not understanding it being a recurring problem. There is a recurring misunderstanding that attributes are applying to a type when they are defined as applying to the declaration.

What is type of an impure function that return a pure, extern(C) function n D ?

Currently, it exists, yet cannot be named, and the formatted output of the compiler is wrong. alias extern(C) int function()pure P; P foo(){ return null; } pragma(msg, typeof(&foo)); => "extern (C) int function() pure function()"
Apr 19 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/19/2013 11:12 PM, deadalnix wrote:
 But some time, you can't
 alias (in case of inference for instance) and so can't choose what attribute
 bind to.

Example, please.
Apr 19 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/20/2013 1:50 AM, Mehrdad wrote:
 On Saturday, 20 April 2013 at 06:25:09 UTC, Walter Bright wrote:
 On 4/19/2013 11:12 PM, deadalnix wrote:
 But some time, you can't alias (in case of inference for instance) and so
 can't choose what attribute bind to.

Example, please.

Here you go: void foo(T)(extern(C) T function() function() f); Try making the extern(C) apply to each of: 1. the result of f() 2. the result of f()() without breaking foo()'s type inference.

What I've been trying to explain is that there's a difference between a storage class attribute and a type constructor. When pure, for example, is used as a storage class attribute, it applies to the declaration always. When pure is used as a type constructor, it applies to the type, always. There is no ambiguity about this, and no problem about choice. For your example, for purity: void foo(T)(T function() pure function() pure f); The only issue here is that extern(C) is not currently supported as a type constructor. If it were, the example would look like: void foo(T)(T function() extern(C) function() extern(C) f); Again, there is no ambiguity.
Apr 20 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/19/2013 12:34 PM, deadalnix wrote:
 On Friday, 19 April 2013 at 19:06:39 UTC, Walter Bright wrote:
 On 4/19/2013 6:55 AM, deadalnix wrote:
 As of for 2 I'd rather have a standard way to have attribute binding to the
 return type or the declaration. This is a recurring problem, and auto is simply
 one instance of it.

I'm not understanding it being a recurring problem. There is a recurring misunderstanding that attributes are applying to a type when they are defined as applying to the declaration.

What is type of an impure function that return a pure, extern(C) function n D ?

A function foo: extern(C) int function()pure foo() { return null; } A type fp: alias extern(C) int function()pure function() fp;
Apr 19 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/19/2013 11:08 PM, deadalnix wrote:
 On Saturday, 20 April 2013 at 00:03:36 UTC, Walter Bright wrote:
 A function foo:

 extern(C) int function()pure foo() { return null; }

That is not it as foo is extern(C).

That is correct. I was thinking about the pure. The extern(C) can be done in a two step process, as Timon showed.
 In general we lack a mechanism to choose what an attribute bind to.

No, we don't. The attribute binds to the declaration. BTW, in C++ also you gotta do the extern "C" as a two step process to attach it to a function type.
Apr 19 2013
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+d gmail.com> writes:
On Thursday, 18 April 2013 at 05:59:20 UTC, kenji hara wrote:
 It will break existing code.

 int foo() {
     typeof(return) bar() { return 1; }
     return bar();
 }

 typeof(return) represents the return type of foo, that is int.

 Kenji Hara

It wouldn't break the code though. It would change the meaning, but the code would compile just as it did before.
Apr 18 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 19 April 2013 at 12:43:49 UTC, Piotr Szturmaj wrote:
 What about this:

 auto inferReturnTypeAndAttributes() { ... }
 auto(return) inferOnlyReturnType() { ... }

 or since all attributes are constraints, it can be rewritten to:

 auto inferOnlyReturnType() pure nothrow  safe { ... }

 It really doesn't make sense to infer impurity, throwing or 
 unsafety because these are the default.

 I imagine there are some use cases where programmer for example 
 wants to infer all but purity, possibly because some other part 
 of the code relies on pure behavior of his function, and he 
 doesn't care about the other attributes. Example of pure 
 function where nothrow and safety are inferred:

 auto inferAllButPurity() pure { ... }

 To sum up:

 1. auto               - infers all
 2. auto(return)       - infers only a return type
 3. auto fn() attrs... - infers return type and all not 
 specified attributes

 Second and third are equivalent, thus auto(return) is optional.

 There were some voices about breaking overriden functions by 
 adding/inferring superclass function attribute. I think this is 
 an oversight, virtual functions should not have attributes 
 inferred.

I like this. It provides a good balance of control and automation. how would template functions be treated with auto(return)?
Apr 19 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 19 April 2013 at 12:43:49 UTC, Piotr Szturmaj wrote:
 What about this:

 auto inferReturnTypeAndAttributes() { ... }
 auto(return) inferOnlyReturnType() { ... }

 or since all attributes are constraints, it can be rewritten to:

 auto inferOnlyReturnType() pure nothrow  safe { ... }

 It really doesn't make sense to infer impurity, throwing or 
 unsafety because these are the default.

 I imagine there are some use cases where programmer for example 
 wants to infer all but purity, possibly because some other part 
 of the code relies on pure behavior of his function, and he 
 doesn't care about the other attributes. Example of pure 
 function where nothrow and safety are inferred:

 auto inferAllButPurity() pure { ... }

 To sum up:

 1. auto               - infers all
 2. auto(return)       - infers only a return type
 3. auto fn() attrs... - infers return type and all not 
 specified attributes

 Second and third are equivalent, thus auto(return) is optional.

 There were some voices about breaking overriden functions by 
 adding/inferring superclass function attribute. I think this is 
 an oversight, virtual functions should not have attributes 
 inferred.

Except for 2, this is already what is proposed. As of for 2 I'd rather have a standard way to have attribute binding to the return type or the declaration. This is a recurring problem, and auto is simply one instance of it. auto applied to the return type means that we infers the return type, applied to the function it means infers return type AND attributes.
Apr 19 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 19 April 2013 at 19:06:39 UTC, Walter Bright wrote:
 On 4/19/2013 6:55 AM, deadalnix wrote:
 As of for 2 I'd rather have a standard way to have attribute 
 binding to the
 return type or the declaration. This is a recurring problem, 
 and auto is simply
 one instance of it.

I'm not understanding it being a recurring problem. There is a recurring misunderstanding that attributes are applying to a type when they are defined as applying to the declaration.

What is type of an impure function that return a pure, extern(C) function n D ?
Apr 19 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 20 April 2013 at 00:03:36 UTC, Walter Bright wrote:
 A function foo:

 extern(C) int function()pure foo() { return null; }

That is not it as foo is extern(C).
 A type fp:

 alias extern(C) int function()pure function() fp;

Same here. In general we lack a mechanism to choose what an attribute bind to.
Apr 19 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 19 April 2013 at 22:16:43 UTC, Timon Gehr wrote:
 Currently, it exists, yet cannot be named, and the formatted 
 output of the compiler is wrong.

 alias extern(C) int function()pure P;
 P foo(){ return null; }

 pragma(msg, typeof(&foo));

 => "extern (C) int function() pure function()"

Yes you have to use a alias to do this kind of thing. But some time, you can't alias (in case of inference for instance) and so can't choose what attribute bind to.
Apr 19 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 20 April 2013 at 06:24:36 UTC, Walter Bright wrote:
 In general we lack a mechanism to choose what an attribute 
 bind to.

No, we don't. The attribute binds to the declaration.

In general we lack a mechanism to choose what direction we turn to. No, we don't. We always turn to the right.
Apr 19 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Saturday, 20 April 2013 at 06:32:50 UTC, deadalnix wrote:
 On Saturday, 20 April 2013 at 06:24:36 UTC, Walter Bright wrote:
 In general we lack a mechanism to choose what an attribute 
 bind to.

No, we don't. The attribute binds to the declaration.

In general we lack a mechanism to choose what direction we turn to. No, we don't. We always turn to the right.

I am quite sure Walter has meant that linkage attribute was not supposed to be tied to a type by design. If you want to use it, you need a symbol (==declaration) and there can be only one at a time.
Apr 20 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 20 April 2013 at 07:03:55 UTC, Dicebot wrote:
 On Saturday, 20 April 2013 at 06:32:50 UTC, deadalnix wrote:
 On Saturday, 20 April 2013 at 06:24:36 UTC, Walter Bright 
 wrote:
 In general we lack a mechanism to choose what an attribute 
 bind to.

No, we don't. The attribute binds to the declaration.

In general we lack a mechanism to choose what direction we turn to. No, we don't. We always turn to the right.

I am quite sure Walter has meant that linkage attribute was not supposed to be tied to a type by design. If you want to use it, you need a symbol (==declaration) and there can be only one at a time.

You don't need a symbol. They also control the ABI, and this isn't always related to a specific symbol.
Apr 20 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Saturday, 20 April 2013 at 06:25:09 UTC, Walter Bright wrote:
 On 4/19/2013 11:12 PM, deadalnix wrote:
 But some time, you can't alias (in case of inference for 
 instance) and so can't choose what attribute bind to.

Example, please.

Here you go: void foo(T)(extern(C) T function() function() f); Try making the extern(C) apply to each of: 1. the result of f() 2. the result of f()() without breaking foo()'s type inference.
Apr 20 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Saturday, 20 April 2013 at 07:18:42 UTC, deadalnix wrote:
 You don't need a symbol. They also control the ABI, and this 
 isn't always related to a specific symbol.

Well, this is how it probably should be. But looking at current D state I don't see if it was even planned. Can you have an extern without declaring some symbol at the same time within current D grammar?
Apr 20 2013
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/20/13, Walter Bright <newshound2 digitalmars.com> wrote:
 What I've been trying to explain is that there's a difference between a
 storage
 class attribute and a type constructor.

I've mentioned this before, but we need a good definition of these on dlang.org (for example people coming from other languages like Python will have no idea what these mean). Last time I mentioned it I didn't file a bug, but now I have: http://d.puremagic.com/issues/show_bug.cgi?id=9970 Hopefully someone with more knowledge of these can write some documentation.
Apr 20 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--047d7b86db60c788b004da9c4ca0
Content-Type: text/plain; charset=UTF-8

2013/4/18 Walter Bright <newshound2 digitalmars.com>

 On 4/16/2013 8:22 AM, 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<https://github.com/D-Programming-Language/dmd/pull/1877>

What do you think of this: typeof(return) foo(int x) { return x; } ? That would only infer the return type, not the attributes.

It will break existing code. int foo() { typeof(return) bar() { return 1; } return bar(); } typeof(return) represents the return type of foo, that is int. Kenji Hara --047d7b86db60c788b004da9c4ca0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /4/18 Walter Bright <span dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digi= talmars.com" target=3D"_blank">newshound2 digitalmars.com</a>&gt;</span><br=
<blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px=

r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <div class=3D"im">On 4/16/2013 8:22 AM, Andrei Alexandrescu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"> There&#39;s a discussion that may be of interest to the larger community:<b= r> <a href=3D"https://github.com/D-Programming-Language/dmd/pull/1877" target= =3D"_blank">https://github.com/D-<u></u>Programming-Language/dmd/pull/<u></= u>1877</a><br> </blockquote> <br></div> What do you think of this:<br> <br> =C2=A0 =C2=A0 =C2=A0typeof(return) foo(int x) { return x; }<br> <br> ? That would only infer the return type, not the attributes.<br> </blockquote></div><br></div><div class=3D"gmail_extra">It will break exist= ing code.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext= ra"><div class=3D"gmail_extra">int foo() {</div><div class=3D"gmail_extra">= =C2=A0 =C2=A0 typeof(return) bar() { return 1; }</div> <div class=3D"gmail_extra">=C2=A0 =C2=A0 return bar();</div><div class=3D"g= mail_extra">}</div><div><br></div><div>typeof(return) represents the return= type of foo, that is int.<br></div><div><br></div><div>Kenji Hara</div></d= iv></div> --047d7b86db60c788b004da9c4ca0--
Apr 17 2013
prev sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
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

I just want to say I'm pretty gung-ho about the idea of attribute inference. If the interface files are blown up to their full explicit attributes, then the big problem of the PIMPL idiom could be solved, with modular programs getting all the info they need and the original source code still quite trim and easy to write. In the discussion of the possible uses of the 'scope' parameter attribute, and 'ref' safety in general, there's a lot of subtleties. One solution to the subtleties is additional attributes, which might be cumbersome to write individually, but easier if inference were on the table.
Apr 21 2013