October 19, 2009
Chris Nicholson-Sauls wrote:
>> People expecting a slice and using "auto" or templates are in for a rude awakening.
>>
>>
>> Andrei
> 
> I would argue that, if they truly *needed* a slice and are relying on "auto" then they implicitly accept responsibility for putting the [] in place to guarantee that.  In other words:
> auto foo = someFunc()[];
> 
> Or T[]'s and T[new]'s could have an alternative to .dup that does the same thing (return self for T[], and return self[] for T[new]).  Either way, it would be something to point out in the book as a best practice: when expecting a slice, guarantee a slice with []'s.

I understand that, but I also believe it's a symptom of a problem instead of a solution. One of our goals is to make the best practices book as high-level as possible, and integrate many best practices in the language.

The above code, therefore, I put in the bin "stuff that the language's user must keep in mind". At best that should go away.


Andrei
October 19, 2009
Andrei Alexandrescu, el 19 de octubre a las 14:31 me escribiste:
> By the way: implementation of @property has been canceled.

Keep throwing the good news :(

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Es mas posible, que un elefante maneje un cero km a que un camello
habite un departamento de un ambiente.
	-- Peperino PĆ³moro
October 19, 2009
On 19/10/2009 16:57, Leandro Lucarella wrote:
> Andrei Alexandrescu, el 18 de octubre a las 20:16 me escribiste:
>> Here's what I wrote to Walter:
>>
>> ====================
>> I'm going to suggest something terrible - let's get rid of T[new]. I
>> know it's difficult to throw away work you've already done, but
>> really things with T[new] start to look like a Pyrrhic victory. Here
>> are some issues:
>>
>> * The abstraction doesn't seem to come off as crisp and clean as we
>> both wanted;
>>
>> * There are efficiency issues, such as the two allocations that you
>> valiantly tried to eliminate in a subset of cases;
>>
>> * Explaining two very similar but subtly different types to
>> newcomers is excruciatingly difficult (I'll send you a draft of the
>> chapter - it looks like a burn victim who didn't make it);
>>
>> * Furthermore, explaining people when to use one vs. the other is
>> much more difficult than it seems. On the surface, it goes like
>> this: "If you need to append stuff, use T[new]. If not, use T[]."
>> Reality is much more subtle. For one thing, T[new] does not allow
>> contraction from the left, whereas T[] does. That puts T[] at an
>> advantage. So if you want to append stuff and also contract from the
>> left, there's nothing our abstractions can help you with.
>
> I think this is getting overcomplicated. I don't see it as complex, I see
> it like this:
>
> 2 types should be provided: array and slice.
>
> array is a *real* type, storing and owning memory, it should be something
> like this (conceptually):
>
> class array(T)
> {
> 	size_t length;
> 	size_t capacity;
> 	T[capacity] elements;
> }
>
> 1) a pure reference type.
> 2) 1 allocation only (interior pointers are not a problem, the GC have to
>     support them anyways).
> 3) easily appendable (capacity field).
>
> slice should be something like this:
>
> struct slice(T)
> {
> 	size_t length;
> 	T* ptr;
> }
>
> 1) a pure value type.
> 2) no allocation at all, *ever*.
> 3) not appendable at all.
> 4) You can change both ptr and length, and you can mutate the elements (if
>     not immutable).
>
> So a slice is a window to peek a chunk of data.
>
> Then you have the syntax. In this discussion, T[new] is array and T[] is
> slice. I find that syntax very confusing. I think it could be even better
> to just put those 2 types in object.d (well, do public imports of those
> 2 types in object.d) and let the people write:
>
> array!T a;
> slice!T s;
>
> The array literals should be immutable chunks of memory in the static
> memory, as ClassInfo.init. The type of [1,2,3] should be, for example,
> slice!(immutable int), so:
> auto s = [1,2,3];
> should create a slice!(immutable int) with length 3 and ptr pointing to
> the static memory where the [1,2,3] was stored (this is what happens with
> strings, right? So no surprises here, they are consistent).
>
> slice.dup should return an array. If you want to just copy the length and
> ptr members, use assignment (it's a value type, remember)?
>
> auto s = [1,2,3];
> auto t = s;
> assert(s.length == t.length);
> assert(s.ptr == t.ptr);
> assert(&s !=&t);
>
> Assignment of arrays is just a pointer assignment (is a reference type):
>
> auto a = [1,2,3].dup;
> auto b = a;
> assert(a is b);
>
> array.dup returns another array. array[] returns a slice though (you can
> allow implicit casting from array to slice but I don't see the point as
> array[] is short enough and more explicit). slices should not be
> convertible to arrays (use slice.dup for that).
>
>
> Back to the syntax, I think T[new] is *really* confusing. It tell me
> nothing about the type, it provides the same information as calling it
> it wazzzaaap!T for me. I *really* think it would be better to call it
> array!T. But if we have both types, T[] is not clear anymore that is
> a slice, again, you can't figure that out. So maybe T[] should be used for
> arrays, not slices; if you want some syntax sugar I think T[] is more
> guessable to be an array than a slice, and it would be a little more
> backward compatible. Maybe slices can be T[..], but I'm not sure is clear
> enough, again I think we could live with something more explicit like
> array!T and slice!T. But at least slices should be part of the language,
> because that should be the type of "array literals" (damn! that didn't
> sound right =P).
>
>
> I'm missing something? Why this shouldn't work?
>

Vote += 1_000_000;

Also, slices are Ranges so this should integrate with the Ranges in phobos.

October 19, 2009
On Mon, 19 Oct 2009 23:31:37 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Don wrote:
>> Walter Bright wrote:
>>> The purpose of T[new] was to solve the problems T[] had with passing T[] to a function and then the function resizes the T[]. What happens with the original?
>>>
>>> The solution we came up with was to create a third array type, T[new], which was a reference type.
>>>
>>> Andrei had the idea that T[new] could be dispensed with by making a "builder" library type to handle creating arrays by doing things like appending, and then delivering a finished T[] type. This is similar to what std.outbuffer and std.array.Appender do, they just need a bit of refining.
>>>
>>> The .length property of T[] would then become an rvalue only, not an lvalue, and ~= would no longer be allowed for T[].
>>>
>>> We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++.
>>>
>>> What do you think?
>>  Since noone else seems to have said it: The fact that you're both willing to let it go, after having already invested a lot of time in it, is a good sign for the language. Well done.
>
> I'm relieved that somebody mentioned that :o). As soon as we gave up with T[new], people started to sell it to us. We should preemptively post about eliminating feature plans before actually implementing them.
>
> By the way: implementation of @property has been canceled.
>
>
> Andrei

I *really* hope you told it so that we encourage actually implementing it!
I strongly believe attributes and properties are very important for D.
October 19, 2009
Don pisze:
> 
> Since noone else seems to have said it: The fact that you're both willing to let it go, after having already invested a lot of time in it, is a good sign for the language. Well done.

Hey Don, you speak my words. Specially that I can't see good reason for T[new] with present array language support (but that's probably my poor knowledge). Walter's main post and one of the later are reflecting my feelings.

We need some polishing and good library now.

Cheers
Piotrek
October 19, 2009
On 2009-10-19 18:19:34 +0200, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> dsimcha wrote:
>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
>>> Leandro Lucarella wrote:
>>>> Andrei Alexandrescu, el 19 de octubre a las 08:38 me escribiste:
>>>>> For relatively large chunks of memory, the GC keeps a control block.
>>>>> We could add a member size_t requestedSize that keeps the size that
>>>>> was requested with an allocation/reallocation call. The GC can take
>>>>> initiative in overallocating memory and expose primitives such as
>>>>> requestedSize (how much did the program ask for?) and capacity (how
>>>>> much is really allocated?).  With that API, it is possible to
>>>>> implement ~= efficiently.
>>>> That would mean moving the overhead of arrays to the GC, but that overhead
>>>> will be present for *all* objects, arrays or not, so I don't think it will
>>>> be a good idea...
>>> I forgot to mention that ~= would also have a means to communicate the
>>> GC to overallocate. My point is simple: the problem is that slices don't
>>>   store enough info. That info could get in the memory control block.
>> 
>> This is the part of this thread I'm not understanding:  Isn't this info stored
>> already?  The only problem is querying it is slow.  See GC.sizeOf(), and bug 2900.
>>  (2900 is fixed, but it's still slow, and there's still bug 2093.)  What are you
>> proposing that's different from the status quo?
> 
> Sorry, I got confused a bit: you have the size in the array and you can get the capacity from the GC, just slowly. Let's sleep on this some more, it may not be impossible to find a growth scheme that works fast.
> 
> Andrei

The problem with the current state, apart slow access to the capacity, is an ownership problem: which of the possibly multiple slices owns the data after the slice? what happens when multiple slices grow?

In some way the current state is the optimal solution with slice=array.
To improve on this the only way is (I think) to have slice!=array, and this was basically what T[new] was all about (at least in my understanding).

Ownership of data is a difficult problem with arrays, and clearly T[new] and slices is more complex than having slice=array, I would be tempted to say that on the whole having T[new] (or even a library vector type, if T[new] does not improve upon what a library type does), might be a good idea.

Fawzi

October 19, 2009
On 2009-10-19 19:34:04 +0200, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> Denis Koroskin wrote:
>> Put it simple: T[] is a range, and T[new] is a container. They belong to different leagues.
> 
> Define ranges and define containers.
> 
>> Yes, there is a lot common between them, because T[] supports some subset of operations that T[new] support.
> 
> No. You see, even you who have a close perspective on the issue have gotten confused. T[new] does not support assignment from range. So T[] and T[new] are not in a subtyping relationship. They support subtly different primitives.

unless I miss something
a_new[]=slice;
works just as
a[]=slice;

as in any case you have a slice on the left

a=slice; // should redefine the slice

and yes that is (correctly) not supported by T[new]

a=range;
should not be used in general imho because a slice should be a valid range, and I don't want similar operations to have very different results (changing the data or just changing the slice object itself).

Fawzi

October 19, 2009
Denis Koroskin wrote:
> On Mon, 19 Oct 2009 23:31:37 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Don wrote:
>>> Walter Bright wrote:
>>>> The purpose of T[new] was to solve the problems T[] had with passing T[] to a function and then the function resizes the T[]. What happens with the original?
>>>>
>>>> The solution we came up with was to create a third array type, T[new], which was a reference type.
>>>>
>>>> Andrei had the idea that T[new] could be dispensed with by making a "builder" library type to handle creating arrays by doing things like appending, and then delivering a finished T[] type. This is similar to what std.outbuffer and std.array.Appender do, they just need a bit of refining.
>>>>
>>>> The .length property of T[] would then become an rvalue only, not an lvalue, and ~= would no longer be allowed for T[].
>>>>
>>>> We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++.
>>>>
>>>> What do you think?
>>>  Since noone else seems to have said it: The fact that you're both willing to let it go, after having already invested a lot of time in it, is a good sign for the language. Well done.
>>
>> I'm relieved that somebody mentioned that :o). As soon as we gave up with T[new], people started to sell it to us. We should preemptively post about eliminating feature plans before actually implementing them.
>>
>> By the way: implementation of @property has been canceled.
>>
>>
>> Andrei
> 
> I *really* hope you told it so that we encourage actually implementing it!
> I strongly believe attributes and properties are very important for D.

Not if the ones that implement it didn't use attributes before or don't know what they are useful for or how they could be implemented. :-)
October 20, 2009
Andrei Alexandrescu wrote:
> Don wrote:
>> Walter Bright wrote:
>>> The purpose of T[new] was to solve the problems T[] had with passing T[] to a function and then the function resizes the T[]. What happens with the original?
>>>
>>> The solution we came up with was to create a third array type, T[new], which was a reference type.
>>>
>>> Andrei had the idea that T[new] could be dispensed with by making a "builder" library type to handle creating arrays by doing things like appending, and then delivering a finished T[] type. This is similar to what std.outbuffer and std.array.Appender do, they just need a bit of refining.
>>>
>>> The .length property of T[] would then become an rvalue only, not an lvalue, and ~= would no longer be allowed for T[].
>>>
>>> We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++.
>>>
>>> What do you think?
>>
>> Since noone else seems to have said it: The fact that you're both willing to let it go, after having already invested a lot of time in it, is a good sign for the language. Well done.
> 
> I'm relieved that somebody mentioned that :o). As soon as we gave up with T[new], people started to sell it to us. We should preemptively post about eliminating feature plans before actually implementing them.
> 
> By the way: implementation of @property has been canceled.

Yeah, let's just keep the language in the broken state it is, because we can't think of a better solution.

> Andrei
October 20, 2009
grauzone wrote:
> Andrei Alexandrescu wrote:
>> Don wrote:
>>> Walter Bright wrote:
>>>> The purpose of T[new] was to solve the problems T[] had with passing T[] to a function and then the function resizes the T[]. What happens with the original?
>>>>
>>>> The solution we came up with was to create a third array type, T[new], which was a reference type.
>>>>
>>>> Andrei had the idea that T[new] could be dispensed with by making a "builder" library type to handle creating arrays by doing things like appending, and then delivering a finished T[] type. This is similar to what std.outbuffer and std.array.Appender do, they just need a bit of refining.
>>>>
>>>> The .length property of T[] would then become an rvalue only, not an lvalue, and ~= would no longer be allowed for T[].
>>>>
>>>> We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++.
>>>>
>>>> What do you think?
>>>
>>> Since noone else seems to have said it: The fact that you're both willing to let it go, after having already invested a lot of time in it, is a good sign for the language. Well done.
>>
>> I'm relieved that somebody mentioned that :o). As soon as we gave up with T[new], people started to sell it to us. We should preemptively post about eliminating feature plans before actually implementing them.
>>
>> By the way: implementation of @property has been canceled.
> 
> Yeah, let's just keep the language in the broken state it is, because we can't think of a better solution.

Silly me, I was thinking the humor was all too obvious.

Andrei