> auto fun(return(type) a, ...)

auto fun(ret a, ...) ?

Actually, I can make it a library solution right now.
Just provide a template, which takes a symbolic representation of
constness and a type and constructs the appropriately const type.
And a template, which extracts the const-ness of a type.
It's gonna look ugly, but it will work.

On Tue, Nov 8, 2011 at 9:02 PM, so <so@so.so> wrote:
> On Tue, 08 Nov 2011 18:56:59 +0200, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
>
>> Unless you write a template constraint, this will force you to use the same type, instead of the same storage class.
>>
>> On Tue, Nov 8, 2011 at 8:42 PM, so <so@so.so> wrote:
>>>
>>> On Tue, 08 Nov 2011 16:39:35 +0200, so <so@so.so> wrote:
>>>
>>>> auto fun(return(type) a, ...)
>>>> return(T) fun(return(S) a, ...)
>>>
>>> Damn, nobody likes it, and i was expecting at least a nobel prize on math.
>>>
>
> return(T) fun(return(S) a, ...)
>
> Functions just like inout right now, and with:
>
> auto fun(return(type) a, ...)
>
> I meant to suggest if not said otherwise (as in the case above) we can just
> go return what it was passed.
> (I am not sure, probably inout already does this too)
>

On Tue, 08 Nov 2011 19:21:50 +0200, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:

> Actually, I can make it a library solution right now.
> Just provide a template, which takes a symbolic representation of
> constness and a type and constructs the appropriately const type.
> And a template, which extracts the const-ness of a type.
> It's gonna look ugly, but it will work.

How ugly it can get, it is a keyword of its own, for single purpose! :)

On Tue, 08 Nov 2011 19:20:49 +0200, RivenTheMage <riven-mage@id.ru> wrote:

>> auto fun(return(type) a, ...)
>
> auto fun(ret a, ...) ?

Don't dare take my ret away, unless you give back something that really counts.

Polluting keyword space is not a good idea unless it's impossible to
interfere with identifiers.
If keywords used a special syntax, like starting with a special
character, then this wouldn't be an issue

On Tue, Nov 8, 2011 at 9:28 PM, so <so@so.so> wrote:
> On Tue, 08 Nov 2011 19:21:50 +0200, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
>
>> Actually, I can make it a library solution right now.
>> Just provide a template, which takes a symbolic representation of
>> constness and a type and constructs the appropriately const type.
>> And a template, which extracts the const-ness of a type.
>> It's gonna look ugly, but it will work.
>
> How ugly it can get, it is a keyword of its own, for single purpose! :)
>

On Tue, 08 Nov 2011 02:08:27 +0100, Walter Bright <newshound2@digitalmars.com> wrote:

> http://drdobbs.com/blogs/cpp/231902461
>
> Anyone want to do the reddit honors?

I personally find it much more astonishing that inout methods finally work.

All of this with one method definition, without const_cast macros, without overload ambiguities
but with transitive qualifier safety.

----
import std.stdio;

class C
{
    inout(int) foo() inout
    {
        return a;
    }
    int a;
}

void printType(T)(T t)
{
    writeln(typeid(t.foo()));
}

void main()
{
    auto a = new immutable(C)();
    auto b = new C();

    printType!(immutable C)(a);
    printType!(const C)(a);
    printType!(const C)(b);
    printType!(C)(b);
}

On 11/8/2011 6:39 AM, so wrote:
> auto fun(return(type) a, ...)
> return(T) fun(return(S) a, ...)

Thought about using 'return', but it just looked confusing as hell (think about lambdas).

On 11/8/11 10:42 AM, so wrote:
> On Tue, 08 Nov 2011 16:39:35 +0200, so <so@so.so> wrote:
>
>> auto fun(return(type) a, ...)
>> return(T) fun(return(S) a, ...)
>
> Damn, nobody likes it, and i was expecting at least a nobel prize on math.

If it makes you feel better, this was on the table. We settled for inout. It's water under the bridge. Let's not waste time on this.

Andrei

Le 08/11/2011 20:33, Andrei Alexandrescu a écrit :
> On 11/8/11 10:42 AM, so wrote:
>> On Tue, 08 Nov 2011 16:39:35 +0200, so <so@so.so> wrote:
>>
>>> auto fun(return(type) a, ...)
>>> return(T) fun(return(S) a, ...)
>>
>> Damn, nobody likes it, and i was expecting at least a nobel prize on
>> math.
>
> If it makes you feel better, this was on the table. We settled for
> inout. It's water under the bridge. Let's not waste time on this.
>
> Andrei

You should definitively communicate more on that. Especially, what are the points that made inout the « winning » solution ?

On 08-11-2011 15:02, Gor Gyolchanyan wrote:
>> Well use of auto can be ambiguous here I think.
>
> I'm not sure, frankly. We should consult with Walter and co. because
> they have a better idea about syntax readability.

I know I wouldn't enjoy typing three keywords on a single parameter. :)

>
>> What about auto const ref ?
>
> That will force you to have both auto const and auto ref at the same time.
>
> On Tue, Nov 8, 2011 at 5:48 PM, deadalnix<deadalnix@gmail.com>  wrote:
>> Le 08/11/2011 14:36, Gor Gyolchanyan a écrit :
>>>
>>> I agree with _inout_ being a bad choice.
>>> I'd rather use something involving _auto_, because this kind of use of
>>> _auto_ is already employed in _auto ref_ parameters and is visually
>>> unambiguous.
>>> Probably _auto const_ would do the trick.
>>>
>>> The actual _inout_ keyword could be flagged as deprecated and removed
>>> during the next breaking change in D (along with all other wonderful
>>> breaking changes that were proposed).
>>>
>>
>> Well use of auto can be ambiguous here I think.
>>
>> What about auto const ref ?
>>

- Alex