So this idea spawned from a thread I posted over in learn[1]. Similar to how you can mark a member function as const or immutable, there should be a way to mark a delegate as const or immutable.

For a member function, marking it const/immutable means the this* will be const/immutable. For a delegate, marking it const/immutable should mean that the context* will be const/immutable. This already happens for delegates to member functions, but I think this would be valuable for all delegates in general.

Const on a delegate would just implicitly convert everything in the context to const.
ie:
void foo()
{
     int x = 4;
     auto bar = () const
     {
          x++;// error, x is const
     };
     x++;// Ok
}

Immutable on a delegate would require every thing in the context to be immutable. Because you can't just implicitly convert to immutable this means any variable use in the context must be immutable.
ie:
void foo()
{
     int x = 4;
     immutable int y = 4;
     auto bar = () immutable
     {
          return x;// error, x is not immutable
     };

     auto bar2 = () immutable
     {
          return y;// Ok
     };
}

One of the benefits of the immutable attribute would be to ensure strong purity on delegates. For instance currently a delegate marked pure could still change if either A) it modifies its own context, or B) the function that created the context still has not returned and it modifies the context. Being able to annotate it as const fixes A, being able to annotate it as immutable fixes both A and B.

Thoughts?

[1] http://forum.dlang.org/thread/dpyncfsfjinwjvkzeomk@forum.dlang.org

On Friday, 3 July 2015 at 00:26:40 UTC, Tofu Ninja wrote:
> So this idea spawned from a thread I posted over in learn[1]. Similar to how you can mark a member function as const or immutable, there should be a way to mark a delegate as const or immutable.
>

http://wiki.dlang.org/DIP30

On 07/03/2015 02:26 AM, Tofu Ninja wrote:
> So this idea spawned from a thread I posted over in learn[1]. Similar to
> how you can mark a member function as const or immutable, there should
> be a way to mark a delegate as const or immutable.
>...
>
> Thoughts?
>

https://issues.dlang.org/show_bug.cgi?id=14745

On 07/03/2015 03:18 AM, deadalnix wrote:
> On Friday, 3 July 2015 at 00:26:40 UTC, Tofu Ninja wrote:
>> So this idea spawned from a thread I posted over in learn[1]. Similar
>> to how you can mark a member function as const or immutable, there
>> should be a way to mark a delegate as const or immutable.
>>
>
> http://wiki.dlang.org/DIP30

That's overkill.

On Friday, 3 July 2015 at 02:13:39 UTC, Timon Gehr wrote:
> On 07/03/2015 02:26 AM, Tofu Ninja wrote:
>> So this idea spawned from a thread I posted over in learn[1]. Similar to
>> how you can mark a member function as const or immutable, there should
>> be a way to mark a delegate as const or immutable.
>>...
>>
>> Thoughts?
>>
>
> https://issues.dlang.org/show_bug.cgi?id=14745

-_-

Is that documented anywhere? I can't find anything in the docs that says nested functions can have immutable, const, shared, inout attached to them. This seems to be a wholly unknown and undocumented feature, and the fact that it doesn't work on anonymous delegates seems like it's not even fully implemented, like someone started to implement it and stopped half way though.

On Friday, 3 July 2015 at 08:35:53 UTC, Tofu Ninja wrote:
> On Friday, 3 July 2015 at 02:13:39 UTC, Timon Gehr wrote:
>> On 07/03/2015 02:26 AM, Tofu Ninja wrote:
>>> So this idea spawned from a thread I posted over in learn[1]. Similar to
>>> how you can mark a member function as const or immutable, there should
>>> be a way to mark a delegate as const or immutable.
>>>...
>>>
>>> Thoughts?
>>>
>>
>> https://issues.dlang.org/show_bug.cgi?id=14745
>
> -_-
>
> Is that documented anywhere? I can't find anything in the docs that says nested functions can have immutable, const, shared, inout attached to them. This seems to be a wholly unknown and undocumented feature, and the fact that it doesn't work on anonymous delegates seems like it's not even fully implemented, like someone started to implement it and stopped half way though.

They can't, it is not implemented. It should e possible and pure is broken for them.

On Friday, 3 July 2015 at 10:59:43 UTC, deadalnix wrote:
> They can't, it is not implemented. It should e possible and pure is broken for them.

void main(string[] args)
{
	void foo() immutable
	{
	}
}

That compiles and works as expected, it seems to be implemented at least for nested functions. I didn't know about it before because it wasn't documented anywhere and it does not work for anonymous delegates. >.>

On Friday, 3 July 2015 at 11:08:46 UTC, Tofu Ninja wrote:
> ...

It even gives nice errors when you try to access mutable data

void main(string[] args){
	int x;
	auto foo() immutable{return x;}
}

Error: pure immutable nested function 'main.main.foo' cannot access mutable data 'x'

Const does not seem to work properly though...
void main(string[] args){
	int x = 0;
	auto foo() const{
		x++;
		return x;
	}
	writeln(foo()); // prints 1
}

On 07/03/2015 10:35 AM, Tofu Ninja wrote:
> On Friday, 3 July 2015 at 02:13:39 UTC, Timon Gehr wrote:
>> On 07/03/2015 02:26 AM, Tofu Ninja wrote:
>>> So this idea spawned from a thread I posted over in learn[1]. Similar to
>>> how you can mark a member function as const or immutable, there should
>>> be a way to mark a delegate as const or immutable.
>>> ...
>>>
>>> Thoughts?
>>>
>>
>> https://issues.dlang.org/show_bug.cgi?id=14745
>
> -_-
>
> Is that documented anywhere? I can't find anything in the docs that says
> nested functions can have immutable, const, shared, inout attached to
> them. This seems to be a wholly unknown and undocumented feature, and
> the fact that it doesn't work on anonymous delegates seems like it's not
> even fully implemented, like someone started to implement it and stopped
> half way though.

I assume the related commits are listed here: https://issues.dlang.org/show_bug.cgi?id=9148

The last of them are after the 2.067.1 release, so maybe it already works correctly in master. Otherwise the issue should be reopened.