Thread overview | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
September 29, 2014 @safe pure nothrow compiler inference | ||||
---|---|---|---|---|
| ||||
So somehow I missed that for template functions the attributes can be inferred. From what I can tell it has to do with having the body available. But when not using .di files, why can't it be done for regular functions? Atila |
September 29, 2014 Re: @safe pure nothrow compiler inference | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | On Monday, 29 September 2014 at 14:32:16 UTC, Atila Neves wrote:
> So somehow I missed that for template functions the attributes can be inferred. From what I can tell it has to do with having the body available. But when not using .di files, why can't it be done for regular functions?
>
> Atila
It can be done, Walter wanted to do it, but there was large resistance, mainly because library APIs would become unstable, possibly changing between every release.
IMHO it would be safe to use inference for private functions...
Daniel N
|
September 29, 2014 Re: @safe pure nothrow compiler inference | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | On 9/29/14 10:32 AM, Atila Neves wrote:
> So somehow I missed that for template functions the attributes can be
> inferred. From what I can tell it has to do with having the body
> available. But when not using .di files, why can't it be done for
> regular functions?
There was a push to do it for ctors, and require them to be available. I think this was actually discussed by Walter at one conference talk (maybe you missed it).
I think we should have an @infer property that would infer the properties and require the function body in .di (compiler would output it for .di generation also).
For various reasons, this all fell through.
-Steve
|
October 01, 2014 Re: @safe pure nothrow compiler inference | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel N | On 9/29/2014 7:40 AM, Daniel N wrote: > On Monday, 29 September 2014 at 14:32:16 UTC, Atila Neves wrote: >> So somehow I missed that for template functions the attributes can be >> inferred. From what I can tell it has to do with having the body >> available. But when not using .di files, why can't it be done for >> regular functions? >> >> Atila > > It can be done, Walter wanted to do it, but there was large resistance, > mainly because library APIs would become unstable, possibly changing > between every release. I wanted to do it for "auto" returning functions, since they require a function body. > IMHO it would be safe to use inference for private functions... Not a bad idea. Please file as an enhancement request. The more attribute inference we can do, the better. |
October 01, 2014 Re: @safe pure nothrow compiler inference | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright |
> I wanted to do it for "auto" returning functions, since they require a function body.
>
Is there any good reason to _not_ do it for auto return functions?
Atila
|
October 01, 2014 Re: @safe pure nothrow compiler inference | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel N | On Monday, 29 September 2014 at 14:40:34 UTC, Daniel N wrote:
> It can be done, Walter wanted to do it, but there was large resistance, mainly because library APIs would become unstable, possibly changing between every release.
Huh? Templates are part of library API too, see std.algorithm. So what's the difference if the API consists of templated or non-templated functions? Why for one part of API it's ok to change with every release and for the other not ok?
|
October 01, 2014 Re: @safe pure nothrow compiler inference | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On Wednesday, 1 October 2014 at 15:12:41 UTC, Kagamin wrote:
> On Monday, 29 September 2014 at 14:40:34 UTC, Daniel N wrote:
>> It can be done, Walter wanted to do it, but there was large resistance, mainly because library APIs would become unstable, possibly changing between every release.
>
> Huh? Templates are part of library API too, see std.algorithm. So what's the difference if the API consists of templated or non-templated functions? Why for one part of API it's ok to change with every release and for the other not ok?
It's not that "it's OK for templates", it's that you *must* have inference.
This was not an argument against having inference for normal functions.
|
Copyright © 1999-2021 by the D Language Foundation