On 12/3/2015 12:59 PM, Dicebot wrote:
> This isn't any different from namespace struct idiom, is it? I don't like it
> because it forces the namespace usage even if it isn't needed.

If you use mixin templates, you can use or not use the namespace. prefix.

On 12/3/2015 1:05 PM, FreeSlave wrote:
> When talking about namespaces in the C++ sense, the feature of namespace is that
> it can be scattered among many files and can be 'using'.

I call that a bug, not a feature, since one loses all control over overloading of names and encapsulation.

If you're going to do that, it's better to simply use _ instead of .

   namespace_name

instead of:

   namespace.name

On 2015-12-03 22:02, Dicebot wrote:
> And for that specific "stable" example - just make it a separate module,
> problem solved. To make use of module system for symbol resolution one
> needs to have many small modules, _that_ should become D idiom.

I agree. I will just be difficult to convince the core developers of that.

-- 
/Jacob Carlborg

On 12/3/2015 1:29 PM, Andrei Alexandrescu wrote:
> FWIW I wanted to use it to allow lst.linear.stable.insert() and
> lst.stable.linear.insert() to refer to the same function, but this is not
> working. Qualifies as a bug?

I don't want this to become a D idiom. It's too clever, too confusing, too verbose, and nobody knows how it is supposed to work.

On 2015-12-03 23:54, Andrei Alexandrescu wrote:

> Nothing. But one thing I was keeping an eye for would be to allow
> lst.stable.linear.xxx and lst.linear.stable.xxx with one body. -- Andrei

How do you plan to differentiate the functionality?

-- 
/Jacob Carlborg

On Thursday, 3 December 2015 at 22:54:53 UTC, Andrei Alexandrescu wrote:
> Nothing. But one thing I was keeping an eye for would be to allow lst.stable.linear.xxx and lst.linear.stable.xxx with one body. -- Andrei

Please don't. Choose one to be the outer and one to be the inner. Otherwise people will sometimes use one, sometimes the other and code will look inconsistent. Just choose one.

On 12/3/2015 2:54 PM, Andrei Alexandrescu wrote:
> But one thing I was keeping an eye for would be to allow
> lst.stable.linear.xxx and lst.linear.stable.xxx with one body. -- Andrei


lst.xxx!(stable, linear)

On Friday, 4 December 2015 at 07:12:50 UTC, Jacob Carlborg wrote:
> On 2015-12-03 22:02, Dicebot wrote:
>> And for that specific "stable" example - just make it a separate module,
>> problem solved. To make use of module system for symbol resolution one
>> needs to have many small modules, _that_ should become D idiom.
>
> I agree. I will just be difficult to convince the core developers of that.

The idea is about scoping of member functions. There's no way you can achieve this with modules, unless you're thinking of ruby modules and not D modules.

On Friday, 4 December 2015 at 02:59:12 UTC, Steven Schveighoffer wrote:
> FWIW, I don't believe this complexity of API is worth it. It may be you have all this wonderful mechanisms to specify exactly the runtime requirements for your algorithms -- and

Big-Oh isn't particularly useful, but having an upper bound on actual running time is useful in real time programming.

What would be more useful is to have the compiler infer worst case number of cycles or operations or cachelines affected, whether it allocates or not, whether it can lock, whether it can result in system calls etc.

I don't think the handwritten documentation is all that useful, but measured performance using a test suite on a given architecture could be very useful!

On Friday, 4 December 2015 at 08:40:13 UTC, Ola Fosheim Grøstad wrote:
> Big-Oh isn't particularly useful, but having an upper bound on actual running time is useful in real time programming.

And to avoid confusion: in real time applications _everything_ is O(1). Anything worse than that is non-real-time.