On 10/21/2015 02:18 PM, Zz wrote:
>
> While looking at containers take a look at Jiri Soukup's work some good
> ideas could come from there.
>
> http://www.amazon.ca/Serialization-Persistent-Objects-Structures-Efficient/dp/3642393225/ref=sr_1_1?ie=UTF8&qid=1386946808&sr=8-1&keywords=SERIALIZATION+AND+PERSISTENT+OBJECTS#productPromotions%22%20target=%22_blank
>
>
> Intrusive Data Structures.
> http://www.codefarms.com/home
> http://www.codefarms.com/dol
> http://www.codefarms.com/ppf
> http://www.codefarms.com/ptl

Ah, Codefarms is still around. Nice. I remember I've been reading Soukup's articles back in the days of the C++ Report magazine. I couldn't make sense of them, nor could any of my friends. -- Andrei

On 10/21/2015 02:24 PM, Robert burner Schadek wrote:
> On Wednesday, 21 October 2015 at 17:23:15 UTC, Andrei Alexandrescu wrote:
>> Even simpler, hasMethod!(Container, "append") -- Andrei
>
> I know this goes against your talk at DConf, but having to write string
> parameters does not feel good. I'm will properly not be the only one who
> will mistype "apend" and wonder why the other template function will be
> chosen. I rather have the compiler scream at me telling me there is no
> symbol hasApend. And hasAppend!Container is less typing than
> hasMethod!(Container, "append").

Yah, but defining isXxx for dozens of Xxx doesn't sit well either. -- Andrei

On 10/21/2015 02:32 PM, Jonathan M Davis wrote:
> On Wednesday, 21 October 2015 at 18:24:30 UTC, Robert burner Schadek wrote:
>> On Wednesday, 21 October 2015 at 17:23:15 UTC, Andrei Alexandrescu wrote:
>>> Even simpler, hasMethod!(Container, "append") -- Andrei
>>
>> I know this goes against your talk at DConf, but having to write
>> string parameters does not feel good. I'm will properly not be the
>> only one who will mistype "apend" and wonder why the other template
>> function will be chosen. I rather have the compiler scream at me
>> telling me there is no symbol hasApend. And hasAppend!Container is
>> less typing than hasMethod!(Container, "append").
>
> The other concern is that hasMethod isn't going to be checking anything
> other than the name, whereas a hasAppend could actually check that the
> function accepts the right arguments and returns the correct type.
>
> And it's not like the list of the functions to check for is going to be
> infinite. It needs to be a known list of functions where each of those
> functions has a signature that meets certain requirements. You can't
> just be checking for a random function name and expect it to do what you
> want. So, having a list of explicit traits to use for testing for the
> expected set of functions will both allow for the tests to be more
> thorough than simply checking the name, _and_ it will serve as a way to
> help document what the list of expected functions is for a particular
> domain.
>
> I really think that using hasMethod by itself like that is getting too
> ad hoc and doesn't really benefit us over having an explicit list of
> traits for the specific domain that we're dealing with. I totally buy
> that testing for each of the specific functions rather than trying to
> put all of that information in the type itself (e.g.
> ContainerWithAppendAndRemove) simply isn't going to scale, but I don't
> at all buy that using hasMethod to test for the existence of member
> functions is a good way to go.

I'd say let's first have a Pope before becoming more Catholic than him. -- Andrei

On Wednesday, 21 October 2015 at 11:05:12 UTC, Andrei Alexandrescu wrote:
> The question here is what containers are of interest for D's standard library.

I think the ones in the STL work well. So I'd like something along these lines.
Something like std::vector would fit 90% of my needs (eg: a slice using allocators).
No interest in lock-free or immutable containers from here.

On Wednesday, 21 October 2015 at 19:18:44 UTC, Andrei Alexandrescu wrote:
> On 10/21/2015 02:24 PM, Robert burner Schadek wrote:
>> On Wednesday, 21 October 2015 at 17:23:15 UTC, Andrei Alexandrescu wrote:
>>> Even simpler, hasMethod!(Container, "append") -- Andrei
>>
>> I know this goes against your talk at DConf, but having to write string
>> parameters does not feel good. I'm will properly not be the only one who
>> will mistype "apend" and wonder why the other template function will be
>> chosen. I rather have the compiler scream at me telling me there is no
>> symbol hasApend. And hasAppend!Container is less typing than
>> hasMethod!(Container, "append").
>
> Yah, but defining isXxx for dozens of Xxx doesn't sit well either. -- Andrei

So, instead we make it ad hoc where only the name is tested rather than anything about what the function is or does, and we make it that much harder for folks to know what the vocabulary list of functions is, because there's no list of traits to test for them and just a table in some piece of documentation somewhere? I just don't see this scaling well if we're not more rigorous about it than hasMethod!(Container, "append"). If all of the containers are in Phobos and nothing outside of Phobos is actually testing for any of these methods, then it's a much smaller issue, but if any of this method testing is going to happen outside of Phobos, then I definitely think that it's a bad idea to be this ad hoc about it.

- Jonathan M Davis

On Wednesday, 21 October 2015 at 19:19:23 UTC, Andrei Alexandrescu wrote:
> I'd say let's first have a Pope before becoming more Catholic than him. -- Andrei

I confess that I really don't understand that one.

- Jonathan M Davis

On Wednesday, 21 October 2015 at 19:16:28 UTC, Andrei Alexandrescu wrote:
> Sometimes you want a value container as a member of a struct which in turn is a value type.

Sure, but at least in theory, the struct's postblit should be able to copy a reference type container via dup or whatnot if that's what you really want (though the issues with const and immutable interacting badly with postblit remain), and creating a whole set of value type variants of containers just for cases like that (which are sometimes useful but usually a bad idea) seems like overkill.

- Jonathan M Davis

On 10/21/2015 07:25 PM, Andrei Alexandrescu wrote:
>
> It seems to me that's a departure from traditional persistent data
> structures.

I don't think so.

> Those have immutable elements;

Immutable insofar as the elements themselves don't change. It is easy to create a persistent list of immutable references to mutable data in Haskell, for instance.

> far as I can tell you discuss
> containers that only have immutable topology. -- Andrei

The topology as well as all the elements are immutable, just not in the 'transitive qualifier' way. Immutable references to mutable data are useful, they just don't have built-in language support. Persistent data structures work perfectly fine with those.

On Wednesday, 21 October 2015 at 19:38:37 UTC, Jonathan M Davis wrote:
> On Wednesday, 21 October 2015 at 19:19:23 UTC, Andrei Alexandrescu wrote:
>> I'd say let's first have a Pope before becoming more Catholic than him. -- Andrei
>
> I confess that I really don't understand that one.
>
> - Jonathan M Davis

It sounds like he say that you are a bit too orthodox when you argue about the way to test the traits that a Container have.

On 10/21/2015 03:38 PM, Jonathan M Davis wrote:
> On Wednesday, 21 October 2015 at 19:19:23 UTC, Andrei Alexandrescu wrote:
>> I'd say let's first have a Pope before becoming more Catholic than
>> him. -- Andrei
>
> I confess that I really don't understand that one.

"More Catholic than the Pope" = overdoing something all too pedantically. What I mean is: let's get things started and if there's any need for isXxx we'll add them. -- Andrei