V Fri, 10 Dec 2010 11:53:04 +0100, Don wrote:

> Any mutable object returned from a strongly pure function, is guaranteed to be unique.

the function should be probably be safe too, to guarentee to not cast const away.

On 10-dic-10, at 11:53, Don wrote:

> Fawzi Mohamed wrote:
>
>> If one could declare return or out types as unique (note that unique is *not* part of the type, it is like the storage attributes), these methods could be implicitly castable to const or immutable, allowing nicer code.
>> Constructors *might* return unique objects (an object is unique only if all its references are to unique or immutable objects).
>> In several cases uniqueness could be checked by the compiler. I think that such a change would improve part of my code, removing the need for several spurious casts, while at the same time making the code safer.
>
> Any mutable object returned from a strongly pure function, is guaranteed to be unique.

indeed good catch, I was saying that in some occasions the compiler can verify uniqueness, that is indeed an important case.

But I don't understand if you want to imply that uniqueness should not be explicit, but just guaranteed to be detected and used in some occasions, as in the case you gave.

Because any object builder (as for example an array concatenate object) cannot be pure, but can still return an unique object.

about front_const , there I thought harder about having an implicit only use of it, but also there I think that it is not such a good idea

On Fri, 10 Dec 2010 07:40:49 -0500, Fawzi Mohamed <fawzi@gmx.ch> wrote:

>
> On 10-dic-10, at 11:53, Don wrote:
>
>> Fawzi Mohamed wrote:
>>
>>> If one could declare return or out types as unique (note that unique is *not* part of the type, it is like the storage attributes), these methods could be implicitly castable to const or immutable, allowing nicer code.
>>> Constructors *might* return unique objects (an object is unique only if all its references are to unique or immutable objects).
>>> In several cases uniqueness could be checked by the compiler. I think that such a change would improve part of my code, removing the need for several spurious casts, while at the same time making the code safer.
>>
>> Any mutable object returned from a strongly pure function, is guaranteed to be unique.
>
> indeed good catch, I was saying that in some occasions the compiler can verify uniqueness, that is indeed an important case.
>
> But I don't understand if you want to imply that uniqueness should not be explicit, but just guaranteed to be detected and used in some occasions, as in the case you gave.
>
> Because any object builder (as for example an array concatenate object) cannot be pure, but can still return an unique object.

I'm not sure I understand your example, but why not?  Pure functions have gotten a lot better in the last release (with the possibility of weakly-pure functions).

I agree with Don, let's make strongly-pure functions implicitly castable and see how far we can get.  If we can do uniqueness without having to mess with the type system, then it will be much easier to deal with.

-Steve

On 06/12/2010 19:00, Jonathan M Davis wrote:
> On Monday, December 06, 2010 05:41:42 Steven Schveighoffer wrote:
>> On Mon, 06 Dec 2010 04:44:07 -0500, spir<denis.spir@gmail.com>  wrote:
>>> On Mon, 6 Dec 2010 00:31:41 -0800
>>>
>>> Jonathan M Davis<jmdavisProg@gmx.com>  wrote:
>>>> toString() (or writeFrom() or whatever
>>>> it's going to become)
>>>
>>> guess it was writeTo() ;-) but "writeFrom" is nice as well, we should
>>> find some useful use for it
>>
>> It was proposed as writeTo, but I'm not opposed to a different name.
>
> I have no problem with writeTo(). I just couldn't remember what it was and
> didn't want to take the time to look it up, and the name isn't as obvious as
> toString(), since it's not a standard name which exists in other languages, and
> it isn't actually returning anything. Whether it's to or from would depend on
> how you look at it - to the given delegate or from the object. But writeTo() is
> fine. Once it's used, it'll be remembered.
>

I don't think it's entirely fine. It should at least have "string"/"String" somewhere in the name. (I mentioned this on the other original thread,  although late in time)


-- 
Bruno Medeiros - Software Engineer

On Tue, 21 Dec 2010 13:10:12 -0500, Bruno Medeiros <brunodomedeiros+spam@com.gmail> wrote:

> On 06/12/2010 19:00, Jonathan M Davis wrote:
>> On Monday, December 06, 2010 05:41:42 Steven Schveighoffer wrote:
>>> On Mon, 06 Dec 2010 04:44:07 -0500, spir<denis.spir@gmail.com>  wrote:
>>>> On Mon, 6 Dec 2010 00:31:41 -0800
>>>>
>>>> Jonathan M Davis<jmdavisProg@gmx.com>  wrote:
>>>>> toString() (or writeFrom() or whatever
>>>>> it's going to become)
>>>>
>>>> guess it was writeTo() ;-) but "writeFrom" is nice as well, we should
>>>> find some useful use for it
>>>
>>> It was proposed as writeTo, but I'm not opposed to a different name.
>>
>> I have no problem with writeTo(). I just couldn't remember what it was and
>> didn't want to take the time to look it up, and the name isn't as obvious as
>> toString(), since it's not a standard name which exists in other languages, and
>> it isn't actually returning anything. Whether it's to or from would depend on
>> how you look at it - to the given delegate or from the object. But writeTo() is
>> fine. Once it's used, it'll be remembered.
>>
>
> I don't think it's entirely fine. It should at least have "string"/"String" somewhere in the name. (I mentioned this on the other original thread,  although late in time)

First, I'll say that it's not as important to me as it seems to be to you, and I think others feel the same way.  writeTo seems perfectly fine to me, and the 'string' part is implied by the char[] parameter for the delegate.

Changing the name to contain 'string' is fine as long as:

1) it's not toString.  This is already established as "returning a string" in both prior D and other languages.  I think this would be too confusing.
2) it's short.  I don't want writeAsStringTo or something similar.

What did you have in mind?

-Steve

Hmm.. if we get uniform function call syntax for all types, perhaps this code might even work some day:

import std.stdio;
import std.conv;

string toString(A)(A a)
{
    return to!string(a);
}

class A
{
    string name;
    this(string name)
    {
        this.name = name;
    }
    string writeTo()
    {
        return name;
    }
}

void main()
{
    auto foo = new A("I'm foo! ");
    writeln(foo.toString);  // using uniform function call syntax
}

Right now this code will compile but it will use Object's toString instead of the one we defined above.




On 12/21/10, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> On Tue, 21 Dec 2010 13:10:12 -0500, Bruno Medeiros <brunodomedeiros+spam@com.gmail> wrote:
>
>> On 06/12/2010 19:00, Jonathan M Davis wrote:
>>> On Monday, December 06, 2010 05:41:42 Steven Schveighoffer wrote:
>>>> On Mon, 06 Dec 2010 04:44:07 -0500, spir<denis.spir@gmail.com>  wrote:
>>>>> On Mon, 6 Dec 2010 00:31:41 -0800
>>>>>
>>>>> Jonathan M Davis<jmdavisProg@gmx.com>  wrote:
>>>>>> toString() (or writeFrom() or whatever
>>>>>> it's going to become)
>>>>>
>>>>> guess it was writeTo() ;-) but "writeFrom" is nice as well, we should
>>>>> find some useful use for it
>>>>
>>>> It was proposed as writeTo, but I'm not opposed to a different name.
>>>
>>> I have no problem with writeTo(). I just couldn't remember what it was
>>> and
>>> didn't want to take the time to look it up, and the name isn't as
>>> obvious as
>>> toString(), since it's not a standard name which exists in other
>>> languages, and
>>> it isn't actually returning anything. Whether it's to or from would
>>> depend on
>>> how you look at it - to the given delegate or from the object. But
>>> writeTo() is
>>> fine. Once it's used, it'll be remembered.
>>>
>>
>> I don't think it's entirely fine. It should at least have "string"/"String" somewhere in the name. (I mentioned this on the other original thread,  although late in time)
>
> First, I'll say that it's not as important to me as it seems to be to you, and I think others feel the same way.  writeTo seems perfectly fine to me, and the 'string' part is implied by the char[] parameter for the delegate.
>
> Changing the name to contain 'string' is fine as long as:
>
> 1) it's not toString.  This is already established as "returning a string" in both prior D and other languages.  I think this would be too confusing. 2) it's short.  I don't want writeAsStringTo or something similar.
>
> What did you have in mind?
>
> -Steve
>

On Tue, 21 Dec 2010 19:46:11 +0100, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> Hmm.. if we get uniform function call syntax for all types, perhaps
> this code might even work some day:
>
> import std.stdio;
> import std.conv;
>
> string toString(A)(A a)
> {
>     return to!string(a);
> }
>
> class A
> {
>     string name;
>     this(string name)
>     {
>         this.name = name;
>     }
>     string writeTo()
>     {
>         return name;
>     }
> }
>
> void main()
> {
>     auto foo = new A("I'm foo! ");
>     writeln(foo.toString);  // using uniform function call syntax
> }
>
> Right now this code will compile but it will use Object's toString
> instead of the one we defined above.

It would still use Object's toString, as member functions would be
tested for first.

-- 
Simen

On 12/21/10 12:19 PM, Steven Schveighoffer wrote:
> On Tue, 21 Dec 2010 13:10:12 -0500, Bruno Medeiros
> <brunodomedeiros+spam@com.gmail> wrote:
>
>> On 06/12/2010 19:00, Jonathan M Davis wrote:
>>> On Monday, December 06, 2010 05:41:42 Steven Schveighoffer wrote:
>>>> On Mon, 06 Dec 2010 04:44:07 -0500, spir<denis.spir@gmail.com> wrote:
>>>>> On Mon, 6 Dec 2010 00:31:41 -0800
>>>>>
>>>>> Jonathan M Davis<jmdavisProg@gmx.com> wrote:
>>>>>> toString() (or writeFrom() or whatever
>>>>>> it's going to become)
>>>>>
>>>>> guess it was writeTo() ;-) but "writeFrom" is nice as well, we should
>>>>> find some useful use for it
>>>>
>>>> It was proposed as writeTo, but I'm not opposed to a different name.
>>>
>>> I have no problem with writeTo(). I just couldn't remember what it
>>> was and
>>> didn't want to take the time to look it up, and the name isn't as
>>> obvious as
>>> toString(), since it's not a standard name which exists in other
>>> languages, and
>>> it isn't actually returning anything. Whether it's to or from would
>>> depend on
>>> how you look at it - to the given delegate or from the object. But
>>> writeTo() is
>>> fine. Once it's used, it'll be remembered.
>>>
>>
>> I don't think it's entirely fine. It should at least have
>> "string"/"String" somewhere in the name. (I mentioned this on the
>> other original thread, although late in time)
>
> First, I'll say that it's not as important to me as it seems to be to
> you, and I think others feel the same way. writeTo seems perfectly fine
> to me, and the 'string' part is implied by the char[] parameter for the
> delegate.
>
> Changing the name to contain 'string' is fine as long as:
>
> 1) it's not toString. This is already established as "returning a
> string" in both prior D and other languages. I think this would be too
> confusing.
> 2) it's short. I don't want writeAsStringTo or something similar.
>
> What did you have in mind?
>
> -Steve

Conversion to text should be called toText. That makes the essence of the function visible (it emits characters) without tying the representation of the text.

Andrei

On 12/21/10, Simen kjaeraas <simen.kjaras@gmail.com> wrote:
> It would still use Object's toString, as member functions would be tested for first.
>
> --
> Simen
>

I'm talking about the case where Object's toString function doesn't exist (in some future release of D), but is replaced with writeTo or some alternate name. In that case your old code could still compile by adding this toString template.

On 21/12/2010 19:17, Andrei Alexandrescu wrote:
> On 12/21/10 12:19 PM, Steven Schveighoffer wrote:
>> On Tue, 21 Dec 2010 13:10:12 -0500, Bruno Medeiros
>> <brunodomedeiros+spam@com.gmail> wrote:
>>
>>> On 06/12/2010 19:00, Jonathan M Davis wrote:
>>>> On Monday, December 06, 2010 05:41:42 Steven Schveighoffer wrote:
>>>>> On Mon, 06 Dec 2010 04:44:07 -0500, spir<denis.spir@gmail.com> wrote:
>>>>>> On Mon, 6 Dec 2010 00:31:41 -0800
>>>>>>
>>>>>> Jonathan M Davis<jmdavisProg@gmx.com> wrote:
>>>>>>> toString() (or writeFrom() or whatever
>>>>>>> it's going to become)
>>>>>>
>>>>>> guess it was writeTo() ;-) but "writeFrom" is nice as well, we should
>>>>>> find some useful use for it
>>>>>
>>>>> It was proposed as writeTo, but I'm not opposed to a different name.
>>>>
>>>> I have no problem with writeTo(). I just couldn't remember what it
>>>> was and
>>>> didn't want to take the time to look it up, and the name isn't as
>>>> obvious as
>>>> toString(), since it's not a standard name which exists in other
>>>> languages, and
>>>> it isn't actually returning anything. Whether it's to or from would
>>>> depend on
>>>> how you look at it - to the given delegate or from the object. But
>>>> writeTo() is
>>>> fine. Once it's used, it'll be remembered.
>>>>
>>>
>>> I don't think it's entirely fine. It should at least have
>>> "string"/"String" somewhere in the name. (I mentioned this on the
>>> other original thread, although late in time)
>>
>> First, I'll say that it's not as important to me as it seems to be to
>> you, and I think others feel the same way. writeTo seems perfectly fine
>> to me, and the 'string' part is implied by the char[] parameter for the
>> delegate.
>>
>> Changing the name to contain 'string' is fine as long as:
>>
>> 1) it's not toString. This is already established as "returning a
>> string" in both prior D and other languages. I think this would be too
>> confusing.
>> 2) it's short. I don't want writeAsStringTo or something similar.
>>
>> What did you have in mind?
>>
>> -Steve
>
> Conversion to text should be called toText. That makes the essence of
> the function visible (it emits characters) without tying the
> representation of the text.
>
> Andrei

I don't understand this point. The representation of the text is tied, it's going to be char[] ( aka UTF-8). Unless you were planning to have overloads of toText, but that sounds like an awful idea.


-- 
Bruno Medeiros - Software Engineer