On 6/9/15 7:38 PM, Jonathan M Davis wrote:
> On Tuesday, 9 June 2015 at 22:37:32 UTC, Andrei Alexandrescu wrote:
>> On 6/9/15 3:11 PM, Jonathan M Davis wrote:
>>> And containers are really the main place, I think, where iterators
>>> actually do better than ranges.
>>
>> I think iterators would need to add huge value to warrant addition. --
>> Andrei
>
> I don't disagree. I think that we should stick with ranges. I just think
> that this is one of the few areas where ranges are actually worse than
> iterators, whereas in most other areas, they're better. The result is
> that some of the idioms that are used with iterators in C++ become
> increasingly unwieldy with ranges - finding an element and removing it
> from the container is probably the simplest example.

What's needed is a simple way to refer to exactly one element. I solved that problem in dcollections.

-Steve

On 6/9/15 6:20 PM, Vladimir Panteleev wrote:
> On Tuesday, 9 June 2015 at 21:53:55 UTC, Andrei Alexandrescu wrote:
>> Also, I think we should stay with libc-based I/O.
>
> Um, won't this mean that the library then won't be usable by any
> application that will want to do more than a few simultaneous queries?
> Database engines usually concentrate on concurrency, not latency, so
> non-asynchronous I/O is only adequate for simple programs.

He hasn't seen the contrast yet :)

In any case, I have zero plans to abandon what I've been working on (glacially) over the last 3 years.

-Steve

Containers seems like the best thing to work on after the allocators. Then you could start using the allocators for the containers, so you can choose different allocation strategies for them.

I'd definitely like to see a standard container for sets, instead of the void[0][T] thing I usually do.

On 6/10/15 12:36 AM, Andrea Fontana wrote:
> ODBC is sql-oriented! If not, call it std.sql or std.database.sql.

Well it's etc.c.odbc :o). -- Andrei

On Tuesday, 9 June 2015 at 22:42:15 UTC, Andrei Alexandrescu wrote:
> With regard to which to work on, I've made my decision: http://38.media.tumblr.com/c51baf89e2f85065d669f3080c2b5cdb/tumblr_inline_n3rsrwCCcQ1qj3ir1.jpg

For those voting, you can stop now: he made his decision.  The Spanish in the image above translates to "Why not both?"

On Wednesday, 10 June 2015 at 07:50:24 UTC, Jacob Carlborg wrote:
> On 2015-06-09 20:49, Brad Anderson wrote:
>
>> 1.  vector/array
>> 2.  hash map
>> 3.  hash set
>> 4.  flat map
>> 5.  flat set
>> 6.  map
>> 7.  set
>> 8.  deque
>> 9.  stack
>> 10. queue
>> 11. linked list
>> 12. hash multimap
>> 13. hash multiset
>> 14. flat multimap
>> 15. flat multiset
>> 16. multimap
>> 17. multiset
>> 18. priority queue
>
>
>> I think RedBlackTree isn't a very good name though. It's long and is an
>> implementation detail.
>
> In that case you would need to remove "hash" and perhaps "flat" from all containers to be consistent. Also "linked list" would be just "list". It would be difficult to come up with better names since there would be name clashes.

I wasn't suggesting those as the names. I just used "hash" because it's familiar to everyone (whereas C++'s unordered_map is a somewhat unusual name).

On 06/09/2015 08:49 PM, Brad Anderson wrote:
>
> Containers that should be in the standard library in order of preference
> (from my C++ STL and Boost experience primarily):
>
> 1.  vector/array
> 2.  hash map
> 3.  hash set
> 4.  flat map
> 5.  flat set
> 6.  map
> 7.  set
> 8.  deque
> 9.  stack
> 10. queue
> 11. linked list
> 12. hash multimap
> 13. hash multiset
> 14. flat multimap
> 15. flat multiset
> 16. multimap
> 17. multiset
> 18. priority queue

Also: persistent versions.

On 6/9/15 6:05 PM, Jonathan M Davis wrote:
> On Tuesday, 9 June 2015 at 18:49:04 UTC, Brad Anderson wrote:
>>  We also have map in the form of RedBlackTree. I think you might be
>> able to use RedBlackTree for a set too but I haven't tried it.
>
> You can, but it's a bit of a pain, because you have to keep passing it a
> tuple where the value gets ignored. We really need a wrapper around it
> to make it cleaner.

Map is a pain. Set is not. The apparatus around RedBlackTree in dcollections to turn it into a map is non-trivial, and is worthy of having in std.container. TreeSet, however, was pretty much straight mapping to implementation calls.

-Steve

On 06/09/2015 01:53 PM, Jacob Carlborg wrote:
>
> I vote for databases. I also vote for an interface that is independent
> of ODBC, but ODBC could be one of the drivers that implements this
> interface. I know that there's a native implementation of the MySQL
> protocol on code.dlang.org.
>

This is kind of my thought, too.

I haven't felt constrained by the lack of containers beyond what's built-in. And if I do, I can look into dcollections. It's arguably an optimization issue anyway. YES, Granted, algorithmic optimization is THE BIGGEST optimization by far, but aside from maybe "big data" domains it doesn't actually enable you to do things you just plain couldn't do at all otherwise.

Databases, OTOH, are something where you either can do it, or you just plain CAN'T. And with D it's currently a bit more on the "can't" side, especially if you don't want your app tied to just one DBMS. And unlike containers, the state of D databases actually HAS been an issue for me.

That said, tossing an ODBC wrapper in phobos doesn't really solve the DB issue. It would certainly be GOOD to have a good ODBC lib for D, no doubt, but:

1. There is apparently question as to whether it belongs in Phobos.

2. There's also question about async I/O. A *LOT* of DB users are also going to be Vibe.d users, so we cannot afford to have problems in this area. Perhaps what we need to look at is getting Vibe's async I/O (or at least some low-level portion of it, if that even makes sense?) into Phobos somehow?

3. As useful as ODBC may be, it still doesn't eliminate the need for direct drivers.

4. What's REALLY needed regarding DBs is a good, well-designed low-level interface capable of handling both ODBC and individual drivers. ORMs should be something separate, built on top of this later. This low-level part might either include NoSQL (if reasonable to do so) or leave NoSQL up to a separate interface (if need be).

On 6/11/15 10:59 AM, Nick Sabalausky wrote:
> 2. There's also question about async I/O. A *LOT* of DB users are also
> going to be Vibe.d users, so we cannot afford to have problems in this
> area. Perhaps what we need to look at is getting Vibe's async I/O (or at
> least some low-level portion of it, if that even makes sense?) into
> Phobos somehow?

BTW I'm unclear about the ODBC async support on OSX and Linux, and Internet searches are not making that crystal clear. Does anyone know? -- Andrei