> public final void foo() scope inout @nogc nothrow @safe pure {}
>
> I think the solution is to turn every function into a no-args template, but then you can't use virtual methods.

** sarcasm on **

Don't say that, you give them ideas ;-)

** sarcasm off **

On 8/15/2016 7:48 AM, Chris Wright wrote:
> Oh god, the attribute explosion is getting worse.
>
> I think at this point the proper way to use attribute-based D features is
> to write your code without them, then write a tool that will add all the
> attributes to your source code that it can while not breaking anything.
> Like now it's sensible to write a method:
>
> public final void foo() scope inout @nogc nothrow @safe pure {}
>
> I think the solution is to turn every function into a no-args template,
> but then you can't use virtual methods.


We've made a lot of progress with inferring attributes, and I have some ideas to do that even more.

On Mon, Aug 15, 2016 at 02:43:01PM -0700, Walter Bright via Digitalmars-d wrote:
> On 8/15/2016 7:48 AM, Chris Wright wrote:
> > Oh god, the attribute explosion is getting worse.
> > 
> > I think at this point the proper way to use attribute-based D features is to write your code without them, then write a tool that will add all the attributes to your source code that it can while not breaking anything.  Like now it's sensible to write a method:
> > 
> > public final void foo() scope inout @nogc nothrow @safe pure {}
> > 
> > I think the solution is to turn every function into a no-args template, but then you can't use virtual methods.
> 
> 
> We've made a lot of progress with inferring attributes, and I have some ideas to do that even more.

I'm looking forward to the day we have pervasive attribute inferrence throughout the language.  It's the only sane way to deal with attributes, because they inevitably grow unmanageably numerous. In an ideal world I'd say *all* attributes should be inferred (and only specified where the user wishes to ensure the attribute is actually inferred). But in our non-ideal world it would be interesting to see how far we can get.


T

-- 
A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen

On 8/15/2016 4:30 PM, H. S. Teoh via Digitalmars-d wrote:
> I'm looking forward to the day we have pervasive attribute inferrence
> throughout the language.  It's the only sane way to deal with
> attributes, because they inevitably grow unmanageably numerous. In an
> ideal world I'd say *all* attributes should be inferred (and only
> specified where the user wishes to ensure the attribute is actually
> inferred). But in our non-ideal world it would be interesting to see how
> far we can get.

I think we can pretty much get everywhere except for:

1. virtual functions
2. explicit API interfaces
3. separate compilation
4. function pointers
5. recursion

Adding an attribute then becomes a guarantee.

Note how successful this has been for templates.

On 08/12/2016 01:24 PM, Robert burner Schadek wrote:
>> No, the DIP doesn't handle several levels of indirection.
> 
> What about:
> 
> struct Bar { int a; int b }
> auto rcs = RefCountedTree!(string,Bar)();
> 
> fcs["bar"].a = 1337;  // log n
> fcs["bar"].b = 1338;  // log n
> 
> ? I need to pay log n twice to assign two members

Note though that while it won't work with example of `RefCountedSlice` implementation in DIP (which marks return value as scope reducing lifetime to expression), it should be possible to instead mark method itself (== hidden `this` argument) as `return scope` thus saying that return value has same lifetime as `this`.

On Mon, Aug 15, 2016 at 04:46:15PM -0700, Walter Bright via Digitalmars-d wrote:
> On 8/15/2016 4:30 PM, H. S. Teoh via Digitalmars-d wrote:
> > I'm looking forward to the day we have pervasive attribute inferrence throughout the language.  It's the only sane way to deal with attributes, because they inevitably grow unmanageably numerous. In an ideal world I'd say *all* attributes should be inferred (and only specified where the user wishes to ensure the attribute is actually inferred). But in our non-ideal world it would be interesting to see how far we can get.
> 
> I think we can pretty much get everywhere except for:
> 
> 1. virtual functions
> 2. explicit API interfaces

True.


> 3. separate compilation

Under the current state of separate compilation, yes.  But in theory it *should* be possible, at least in some of the common use cases.


> 4. function pointers

But this shouldn't be a problem as long as the function itself is covariant with the pointer?


> 5. recursion
[...]

I think it should be possible even with recursion, at least if there is a non-recursive branch in the function(s). Of course, it may not necessarily be *feasible* to implement the required analysis in the compiler. But maybe for the simplest cases, e.g.:

	auto func(...) {
		if (condition)
			return finalResult;
		else
			return func(...);
	}


T

-- 
If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell

On Monday, 22 August 2016 at 17:22:28 UTC, H. S. Teoh wrote:
> I think it should be possible even with recursion, at least if there is a non-recursive branch in the function(s). Of course, it may not necessarily be *feasible* to implement the required analysis in the compiler. But maybe for the simplest cases, e.g.:
>
> 	auto func(...) {
> 		if (condition)
> 			return finalResult;
> 		else
> 			return func(...);
> 	}
>
>
> T

I must be missing something here, but isn't it trivial to infer attributes for a recursive function? By definition you either have a call to the current function, which is idempotent in regards to attributes, or some non-recursive work that is done, in which case you follow the normal inference algorithm. I know this is exactly the basic case that you have shown, but even for more complex cases such as mutually-recursive functions I can't see this being unmanageable.

On Mon, Aug 22, 2016 at 06:02:20PM +0000, Meta via Digitalmars-d wrote:
> On Monday, 22 August 2016 at 17:22:28 UTC, H. S. Teoh wrote:
> > I think it should be possible even with recursion, at least if there is a non-recursive branch in the function(s). Of course, it may not necessarily be *feasible* to implement the required analysis in the compiler. But maybe for the simplest cases, e.g.:
> > 
> > 	auto func(...) {
> > 		if (condition)
> > 			return finalResult;
> > 		else
> > 			return func(...);
> > 	}
> > 
> > 
> > T
> 
> I must be missing something here, but isn't it trivial to infer attributes for a recursive function? By definition you either have a call to the current function, which is idempotent in regards to attributes, or some non-recursive work that is done, in which case you follow the normal inference algorithm. I know this is exactly the basic case that you have shown, but even for more complex cases such as mutually-recursive functions I can't see this being unmanageable.

Yeah, this can probably be extended to more complex cases. But you may start running into limitations with the current compiler design once the recursion involves multiple functions, since AFAIK the compiler separately compiles each function, so the inference may not be able to resolve two mutually-recursive functions at the same time.  But maybe there's a way around it that I haven't thought of.

In any case, making inference work with recursive functions is an important step in making inroads to maximizing attribute inference throughout the language.


T

-- 
Lottery: tax on the stupid. -- Slashdotter

On 08/22/2016 08:22 PM, H. S. Teoh via Digitalmars-d wrote:
>> 3. separate compilation
> 
> Under the current state of separate compilation, yes.  But in theory it *should* be possible, at least in some of the common use cases.

Separate compilation is perfectly fixable if we agree for it to work on package / static library level and not on module / object file level. But that may need .di generation improvements and the `export` proposed changes from Benjamin.