On Thursday, 8 October 2015 at 16:14:05 UTC, Jonathan M Davis wrote:
> On Thursday, 8 October 2015 at 15:59:23 UTC, bitwise wrote:
>> Again, it's much easier to be careful about this when the author's intent is baked into the class.
>
> That may be, but my point was that it doesn't actually guarantee that the object is going to be destroyed determinstically. That's going to require that the programmer using the object know that it's designed to be destroyed deterministically and program accordingly. Having it be easier for the programmer to figure out whether an object was designed that way is definitely a plus, but it doesn't make it so that they don't have to worry about it.
>
> - Jonathan M Davis

True. I agree with you on this.

All the time, this idea comes to mind when I see people arguing back and forth, thinking that they will eventually converge on some perfectly ideal solution which obviates the need for any real effort.

     Bit

On Thursday, 8 October 2015 at 16:17:49 UTC, bitwise wrote:
>> Classes are inherently reference types given their semantics.
>
> Incorrect.

Inaccurate maybe, but something that has an identity is not a value type. Value types are by definition identity-less. The type system of C/C++/D doesn't really provide guarantees needed to have proper value types.

On Thursday, 8 October 2015 at 16:29:58 UTC, Ola Fosheim Grøstad wrote:
> Inaccurate maybe, but something that has an identity is not a value type. Value types are by definition identity-less. The type system of C/C++/D doesn't really provide guarantees needed to have proper value types.

Why, because you can take their address?

On Thursday, 8 October 2015 at 16:38:31 UTC, Meta wrote:
> Why, because you can take their address?

You or someone you call can take the address. If there is a way to distinguish instances one way or another then it isn't a value, it is an object. Doesn't mean your code is taking the address.

On 10/8/15 5:59 PM, bitwise wrote:
> With DIP74, the ref counting is hard coded into the type itself.

I think that should be the case. -- Andrei

On 10/8/2015 4:15 AM, Ola Fosheim Grøstad wrote:
>
> I personally think that they future is with actor-based programming in
> combination with substructural/behavioural typing since it lends itself
> to distributed computing, multi core etc.
I've recently become curious about the actor model and would like to learn more about it and maybe play around with it a bit. The C++ Actor Framework looks good, but unfortunately it doesn't yet work with MSVC so I'm waiting for that.

> The challenge is making a good
> language for it that is sufficiently performant and still allows
> breaking out actors to other computational units (computers/CPUs).
>
I read a comment* on stack overflow that mentions that the important component is actually environment/platform such as OTP is for Erlang.
I'm not sure how this affects the C++ actor implementations.

*The last answer at: http://stackoverflow.com/questions/8107612/the-actor-model-why-is-erlang-special-or-why-do-you-need-another-language-for

On 10/8/2015 8:51 AM, Ola Fosheim Grøstad wrote:
> On Thursday, 8 October 2015 at 14:13:30 UTC, Jonathan M Davis wrote:
> Yes, in general ownership should not be circular at all. It should be a
> DAG growing from the current actor/process/stack in an unbroken chain of
> ownership-references.
>

+1. Reference counting has not been much of an issue for me since using smart pointers because I rarely if ever need std::shared_ptr. It's about ownership and std::unique_ptr works fine for that. (std::shared_ptr gets overused and shouldn't be a substitute for a GC). Parents can own a resource with std::unique_ptr and distribute access to it using native pointers. You just need to be aware of lifetimes. I guess people might consider that having to worry about lifetime management is a disadvantage but I have no problem with it.

On Thursday, 8 October 2015 at 18:19:51 UTC, Jim Hewes wrote:
> I've recently become curious about the actor model and would like to learn more about it and maybe play around with it a bit. The C++ Actor Framework looks good, but unfortunately it doesn't yet work with MSVC so I'm waiting for that.

Yes, there are libraries, but for it to be pleasant I think language support is needed. I've linked to this video before, but it is quite entertaining if you haven't seen it yet:

https://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask

Carl Hewitt stresses the difference from other concurrency models that use non-determinism by pointing out that a key quality with actor based systems is indeterminism. (i.e. that things may simply evaporate without notice).

Wikipedia has a rather lengthy page on Actors:
https://en.wikipedia.org/wiki/Actor_model

> I read a comment* on stack overflow that mentions that the important component is actually environment/platform such as OTP is for Erlang.
> I'm not sure how this affects the C++ actor implementations.

I don't know much about C++ actor frame works, but if you only want to play with actors then you could give pony-lang.org a spin. Not sure if they really focus on indeterminism, though.

But an interesting property of using actors is that you (in theory) could scale up by migrating actors to other compute nodes. Or run programs on many core CPUs and just keep going even if one core crashes. If indeterminism is assumed then you have to design for unstable communication between actors with more robustness as an outcome (hopefully).

Am Tue, 6 Oct 2015 18:27:28 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 10/4/2015 11:02 AM, bitwise wrote:
> > For example, streams.
> 
> No streams. InputRanges.

... what bitwise said ...
We had this discussion at least once and it did not change my
mind back then: Ranges and streams have overlapping use cases,
but they are not interchangeable. What they have in common is
that they are both lazy and process data from start to end.

=== Composability ===
Streams work on a series of bits coming from the sender. Class
polymorphism allows them to be wrapped into each other as
needed at any point during the transmission. This includes
applying or reversing compression, encryption and endianness
changes. New filter streams can be loaded through DLLs and
extend the hierarchy.

void main()
{
  InputStream is;

  // Simple stream
  is = new FileStream("./test.txt");

  // File from the web, unzipped with a dynamically loaded
  // filter plugin
  is = new HttpStream("http://a.xy/test.gz");
  auto fs = cast(FilterStream) Object.factory("UnGzipStream");
  fs.wrapped = is;
  is = cast(InputStream) fs;

  // One common interface works with all combinations. No need
  // to know the stream types at compile time, no
  // combinatorial template explosion
  processTestFile(is);
}

void processTestFile(InputStream is);

=== Primitives ===
While ranges assume a fixed structure over all elements,
streamed data embeds information about upcoming data types and
sizes. To handle these, instead of getting the next "item"
with .front, streams provide a different set of primitives:
bulk reads, wrappers for basic data types (this is where
endianness filters apply) and often bit-wise reads to handle
compressed data.

=== Buffering ===
Since input ranges/streams can not generally be wound back,
one natural component of streams is a buffer, similar to
what .byLine does for text, but more flexible. A circular
buffer that can grow is a good candidate. Like .byLine it
offers slicing, or generally referencing its contents at the
current read position without copying. Several primitives are
provided to ask for a number of bytes to be buffered or
dropped. This does not only obviate the need to check for "end
of file" or "end of buffer" everywhere but also enables code
reuse in cases like reading a BigInt off a stream, which takes
a char[] as ctor argument. With a buffered stream you increase
the look-ahead until the entire number string is buffered and
can be passed to BigInt() by reference. BigInt could be
changed to be constructible from a range, but the raw
look-ahead enables use of SIMD to scan for end-of-line or
end-of-number that traditional input range primitives don't.

-- 
Marco

On Thursday, 8 October 2015 at 17:21:52 UTC, Andrei Alexandrescu wrote:
> On 10/8/15 5:59 PM, bitwise wrote:
>> With DIP74, the ref counting is hard coded into the type itself.
>
> I think that should be the case. -- Andrei

Can you comment on the status of the next vision document?

    Thanks =)