about const and immutable (again)
Gor Gyolchanyan
gor.f.gyolchanyan at gmail.com
Tue Oct 11 08:45:33 PDT 2011
assert(is(typeof(&foo) : void function(int));
On Tue, Oct 11, 2011 at 6:35 PM, Steven Schveighoffer
<schveiguy at yahoo.com> wrote:
> On Mon, 10 Oct 2011 21:29:08 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 10/10/11 5:55 PM, Don wrote:
>>>
>>> On 06.10.2011 20:56, Steven Schveighoffer wrote:
>>>>
>>>> On Thu, 06 Oct 2011 12:27:16 -0400, Gor Gyolchanyan
>>>> <gor.f.gyolchanyan at gmail.com> wrote:
>>>>
>>>>> I see. Thanks for the detailed answer.
>>>>
>>>> I should clarify one point, I realized I am somewhat inaccurate on the
>>>> reason the type is set to immutable(dchar). In fact, nobody actually
>>>> wrote the immutable(dchar) function, it's just that the element type is
>>>> immutable(dchar). However, the reasons why someone would want to create
>>>> a function that takes an immutable(dchar) function are as I stated -- so
>>>> you don't accidentally change the value.
>>>
>>> That seems like the discussed-and-discarded 'final' storage class for
>>> parameters. But this is worse. It has an *enormous* cost.
>>
>> Walter and I have agreed for a long time that upon function calls with
>> by-value passing, there should be some simple transforms done:
>>
>> 1. If a parameter has no indirections, qual(T) becomes T.
>>
>> 2. qual(T[]) becomes qual(T)[].
>>
>> 3. qual(T*) becomes qual(T)*.
>>
>> This would improve many aspects of the language. Walter never got to
>> implementing it, but I'm bringing this up in case one of the wonderful
>> compiler contributors would want to take it up. Again, I have reasons to
>> believe Walter would approve of the change.
>
> I agree, this would help tremendously. Would this apply to function
> pointers/delegates as well? For example:
>
> void foo(const(int) i) {}
>
> assert(is(typeof(&foo) == void function(int));
>
> I would prefer it not be this way, and rather start defining some implicit
> delegate/function casting. I think D really needs this, not just in the
> area of const.
>
> -Steve
>
More information about the Digitalmars-d
mailing list