Re: extern(C++, ns)

[Walter Bright via Digitalmars-d]

On 1/20/2016 3:53 PM, tsbockman wrote:

The thought of needing to do that for (potentially) every single symbol being
imported is depressing. What happened to DRY?


Since it is completely mechanical, it's an ideal candidate for writing a 
metafunction to do it:


   module stl--
   private import core.stdcpp.vector;
   private import core.stdcpp.string;
   ...
   extern (C++, std)
   {
   mixin(aliasAllNamespaceMembers());
   }

Re: D Article: Memory Safety

[H. S. Teoh via Digitalmars-d-announce]

On Thu, Jan 21, 2016 at 04:59:01AM +, Basile B. via Digitalmars-d-announce 
wrote:
[...]
> Altgough one thing, attributes are not the easy part of D. I've
> recently encountered a case were in the library attributes were
> allright, test OK, and then suddently when I've started to use the
> library in a real life context I had to remove them from the
> library...@safe was unsustainable.

Phobos/druntime still has some ways to go before using it from @safe
code will be painless.  Some pretty fundamental functionality still
isn't @safe (mainly some stuff in object.di that basically interacts
with too many other things that marking one thing as @safe will
percolate throughout pretty much everything, breaking a whole bunch of
stuff at once).

I once tried writing a @safe program, and it didn't take very long
before I threw that idea out the window.  Once main() is @safe, you're
so straitjacketed that you basically can't write anything too much more
complex than Hello World.  (Well, you *could* just slap @trusted on
whatever it is that's holding you back, but then that breaks the promise
of @safe, which defeats the purpose of the entire exercise.)

There's also still a good number of @safe-related bugs on Bugzilla,
several of which involve built-in language constructs that break
@safe-ty outright. Things have improved a bit since I last checked, but
it seems to me that @safe is still not quite ready to live up to its
promise just yet. Maybe in a few more years' time...


> Dealing with attributes is the hardest part of D IMO.  No one is
> forced to btw, there are plenty of other cool things in D but to
> follow the D safety is hard...
[...]

I think Walter has mentioned before that attribute inference is the way
to go, and I agree. Once you start writing carefully-attributed code,
you'll quickly find that your declarations become painfully verbose,
which is never a good sign (it encourages people not to use attributes).
However, attribute inference on templates and auto functions (proposed
last year, don't know if it's implemented yet) alleviates a lot of the
verbosity. Hopefully the scope of attribute inference will increase
until it makes attribute use more widespread in your everyday D code.


T

-- 
MS Windows: 64-bit rehash of 32-bit extensions and a graphical shell for a 
16-bit patch to an 8-bit operating system originally coded for a 4-bit 
microprocessor, written by a 2-bit company that can't stand 1-bit of 
competition.

Re: extern(C++, ns)

[deadalnix via Digitalmars-d]

I'm not sure what situation you're imagining where modules 
would be created with the same names...?




How do you plan to map C++'s standard lib ? One giant hundred 
of thousands of line C++ file ?


Surely it would map by file.

#include  -> import stl.vector;
#include  -> import stl.map;
#include  -> import stl.string;

Perhaps 'stl' may be something else, 'std' is an unfortunate 
conflict with phobos, but this is unique to this case.




But, in this case, I can't have an stl.vector!X which would map 
to an std::vector . The namespacing of symbol has been 
completely changed.



I'd suggest it's the only possible way to make it feel the same.
It's a no-brainer for the binding author, copy and rename .h 
files to

.d, then regex until finished.



That would require to have a similar namespacing, unless 
extern(C++, name) introduce a symbol called name.


Note that the conflict rule can be tuned the same way it is 
specified for multiple alias this and you get something really 
nice.


What case is there where a C++ lib distributing its symbols 
naturally
among modules named accordingly with the original include's 
would

cause confusion when compared against the C++ docs?
Doc says '#include ', I'll 'import 
libname.feature;'

Nothing could be more natural than this.

As a bonus, the project's C++ namespace 'libname' is already 
present in the fully qualified name, it's the top level 
package! No point repeating that as 
'libname.feature.libname.symbol'.


I think it does make sense to make the C++ namespace "skippable", 
alias this style, while keeping it around to disambiguate. It is 
clear that C++ having namespacing and header being decoupled will 
cause problem if namespaces do not introduce a symbol.

Re: Doubt - Static multidimension arrays

[Nemo via Digitalmars-d-learn]

On Tuesday, 19 January 2016 at 20:39:37 UTC, tsbockman wrote:

On Tuesday, 19 January 2016 at 19:14:30 UTC, alb wrote:

   [...]


One other thing you may want to keep in mind when working on 
this kind of thing - when you loop over a multi-dimensional 
array, the order matters.


For large arrays, this:

int[c_max][r_max] arr;

foreach(r; 0 .. r_max)
{
foreach(c; 0 .. c_max)
{
// do something with arr[r][c] here
}
}

Can be *much* faster than this:

int[c_max][r_max] arr;

foreach(c; 0 .. c_max)
{
foreach(r; 0 .. r_max)
{
// do something with arr[r][c] here
}
}

The reason is that the first version access the elements in the 
order that they are actually stored in memory, whereas the 
second forces the CPU to jump between rows for each element.



[...]


You're welcome.

And yes, it can definitely be confusing. I understand why the 
array syntax in D is the way it is, but that still doesn't 
always save me from mixing things up once in a while anyway.


I don't remember where I saw it, but actually, in static 
multi-dimensional arrays, arr[0][1] is next to arr[0][0] in 
memory. You can see it with:


void main () {
  ubyte [7][5] arr;
  import std.stdio : writeln;
  writeln ( & arr[0][0], " ", & arr[0][1], " ", & arr [1][0] );
}

Re: extern(C++, ns)

[Walter Bright via Digitalmars-d]

On 1/20/2016 4:51 PM, Anon wrote:

What would you all say to the following proposal (and should I make a DIP?)


DIPs are always welcome.

Re: So... add maxCount and maxPos?

[Ivan Kazmenko via Digitalmars-d]

On Thursday, 21 January 2016 at 01:11:19 UTC, Andrei Alexandrescu 
wrote:

On 01/20/2016 04:22 PM, Ivan Kazmenko wrote:

1. The minimum or maximum element itself.  I write it as
a.minPos.front.  That's almost fine, but maybe there is a more
expressive way?


Sadly, no. I'm very willing to add an overload of min and max 
for one argument (which fortunately does not compile currently) 
to compute these over a range. In fact literally today I wrote 
r.min and was surprised it didn't work. Would you want to 
embark on that? Code, docs, unittests, the works.


Hmm.  I was at first frustrated by not having min(Range).  But I 
looked for a reason it does not yet exist, and I found one.  Say 
we define min of one argument, which is a range, to be the 
minimum value of that range.  Now, what if we unpack tuples as 
arguments for min, and some tuple happens to have one element, 
which is a range?  Currently, this immediately triggers a compile 
error.  On the other hand, if we add the one-argument range 
version, it will silently produce a value of another type.  As 
all of this may happen only at compile time, and the type system 
is rather strict, hopefully this will hit a compile error down 
the road, but even then, the actual cause will be harder to find.


An example:

-
import std.algorithm, std.range, std.stdio, std.typecons;

alias minBinary = (x, y) => x < y ? x : y;

auto min (Args...) (Args args)
if (args.length > 1)
{
return args.only.reduce!minBinary;
}

auto min (T) (T [] arr)
{
return arr.reduce!minBinary;
}

void main ()
{
writeln (min (3, 1, 2));  // 1
writeln (min ([3, 1, 2]));  // 1
writeln (min (tuple ([5, 6], [1, 2], [3, 4]).expand));  // 
[1, 2]

writeln (min (tuple ([3, 1, 2]).expand));  // 1, huh?
}
-

So, min(Range) + tuple expansion = problem.

An alternative would be to define min(one argument) to just be 
that argument.  That would be consistent with what we have now, 
but violates the principle of least astonishment for newcomers: 
why would min ([3, 1, 2]) return [3, 1, 2] and not 1?  Currently, 
it just does not compile.


So, I convinced myself that the current situation is the lesser 
evil.  Currently, the second and fourth writeln in the example 
just don't compile if we comment out our min functions.


2. The index of minimum or maximum element, mostly using plain 
array as
a range.  I write "a.length - a.minPos.length", and it looks 
completely
unintuitive.  Additionally, when compiling to 64 bits, I 
usually still
want an int to use with other ints around (longs are overkill 
most of
the time), and the cast adds more clobber.  Again, is there a 
better way

to express that?


No better way currently. We could add (min|max)Index but I like 
(min|max)Pos quite a bit. They offer more flexibility for 
non-random access ranges. For random access ranges you should 
soon be able to write a.before(a.minPos).length, for a 
different kind of unintuitiveness :o).


Well, this at least reads a bit like English: take the part of 
"a" before minimum position in "a" and calculate its length.  The 
downside is two uses of "a" which are certain to put more burden 
on the optimizer.


The current "whole length minus length after minimum" is a 
negative wording, which adds to perceived complexity every time 
it is used.


Ivan Kazmenko.

Re: D Article: Memory Safety

[Jakob Ovrum via Digitalmars-d-announce]

On Wednesday, 20 January 2016 at 20:28:03 UTC, Jon D wrote:
This is passes the @safe constraint, but 'stdout.writeln()' and 
'stderr.writeln()' do not. (My program uses stderr.) 
stderr/stdout/stdin are __gshared and can't be referenced by 
safe code. The module level version of writeln, etc., access a 
trusted version of stdout to avoid this.


Yeah, the standard library still has a ways to go even with @safe.

I always imagined that the standard pipes should use shared as 
opposed to __gshared. I don't think the current implementation is 
thread-safe, but I don't know how this affects in memory safety 
in this case.

Re: DIP87: Enhanced Foreign-Language Binding

[Rikki Cattermole via Digitalmars-d]

On 21/01/16 6:46 PM, Anon wrote:
snip


I thought I did a good enough job of explaining that in the DIP so I
wouldn't have to here.


I was trying to explain some better semantics because how it is 
currently with strings can be and is a bit ambiguous.

Re: Compile-Time RNG

[Timon Gehr via Digitalmars-d]

On 01/21/2016 01:32 AM, tsbockman wrote:

On Wednesday, 20 January 2016 at 23:21:04 UTC, CTRNG wrote:

I managed to create a compile-time random number generator.

Proof of concept, with some explanatory comments:
http://dpaste.dzfl.pl/668646ce6d71

Just thought this might be of interest to some of you here.


That's clever (and devious).


It only works because compile-time introspection is ill-defined though. 
I don't expect it to keep working indefinitely.

Re: Walter on his experience as a dev, on running an open source project and D

[thedeemon via Digitalmars-d-announce]

On Wednesday, 20 January 2016 at 11:07:16 UTC, Rikki Cattermole 
wrote:
From what Walter said, they all knew c. So not really too low 
level for them.


To me it looked like:
Walter: "You all write in C, right?"
Audience silent with expression on their faces "What is C? We've 
only heard about JavaScript".

;)

Re: opIndex, opSlice, length for joiner?

[Andrei Alexandrescu via Digitalmars-d]

On 01/20/2016 12:36 PM, Maverick Chardet wrote:

Hi everyone,

After reading the thread "Distributed Memory implementation":
http://forum.dlang.org/post/oqcfifzolmolcvyup...@forum.dlang.org

And more precisely the suggestion of Dragos Carp on page 2:
http://forum.dlang.org/post/txgabyyoutitketlp...@forum.dlang.org

I looked at the joiner source code (std.algorithm.iteration.joiner) and
I have several ideas to make it have the opIndex, opSlice and length
methods under certain conditions.

First question: what do you think of making this possible if all the
considered ranges have opIndex, opSlice and length? I think that all the
ranges types don't have to all implement the three methods in all cases
(for instance length would actually only require ElementType!RoR and
Separator to implement length) but we can discuss all that later...

The most important issue that comes to my mind is that the operations
would not take constant time... A trivial implementation would be in
O(k) where k is the number of joined ranges, and with some
precomputation in O(k) time and space we can make length O(1) and
opIndex and opSlice O(log k)... Would that be a problem?

Thank you in advance for your remarks!


Thanks for askin. Consider chain(), which currently DOES offer random 
access if its constituents to. In that case, the number of ranges 
chained is a compile-time constant dictated by the source code being 
compiled; no data dependency.


In contrast, the performance of joiner()'s proposed primitives would be 
dependent on the data. For your simplest example, length would be linear 
in the number of ranges. One way to improve on that would be to compute 
length upon the first call and then memoize (and update) it. There is a 
risk it could go out of sync if someone changes the ranges involved 
surreptitiously.


One good thing to do here would be to specialize joiner().walkLength. 
Then people writing r.walkLength would benefit from the quicker 
specialized version.


For indexed access, things get a fair amount more complicated. You can't 
afford linear time, so you need some serious data structure to ensure 
good performance there. That seems to take joiner() in a design space 
that makes it less attractive; currently it's a simple spec with a 
somewhat straightforward implementation.



Andrei

Re: So... add maxCount and maxPos?

[Andrei Alexandrescu via Digitalmars-d]

On 01/20/2016 09:36 PM, Ivan Kazmenko wrote:

So, min(Range) + tuple expansion = problem.


OK, convinced. There's of course the option of (min|max)Element. -- Andrei

Re: D Article: Memory Safety

[Jakob Ovrum via Digitalmars-d-announce]

On Wednesday, 20 January 2016 at 19:55:45 UTC, H. S. Teoh wrote:
On Wed, Jan 20, 2016 at 07:25:43PM +, Dicebot via 
Digitalmars-d-announce wrote:

`auto p = () @trusted { return  } ();`

Huh, I thought Andrei was opposed to this idiom? Is it now 
considered reserved for templates or something has changed?


Yeah, I thought this was exactly the case where some of us 
Phobos contributors got lambasted by Andrei and Walter for 
abusing @trusted.


That was for non-templated functions where this approach makes no 
sense. Indeed it is counterproductive, because @trusted on the 
whole function is a better indication of what needs to be 
reviewed for memory safety (the whole function!).


Any exception to the strict usage of @trusted to me smells like 
a time bomb waiting to explode. It may not be today or 
tomorrow, but sooner or later somebody is going to slip up and 
the compiler won't help you. It's bad enough that every single 
change to a @trusted function must be vetted to ensure actual 
safety; now we have to also vet any modification to any 
function that contains @trusted anonymous functions? In a large 
template function, it's too easy to miss these @trusted 
sub-functions, because if the code change is far away enough, 
the @trusted annotation won't even show up in the diff. So 
reviewers may not even realize it's a change that may have 
broken @trusted.


It is the only way to solve this problem.

Re: Functions that return type

[thedeemon via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 04:27:27 UTC, blm768 wrote:

I guess the constraints are that of a static language.


(This is not true.)


I'm playing with the design of such a language myself. 
Basically, anything can create/use/return type objects


This is usually possible in dependently typed languages such as 
Idris, Agda or Coq. Check out Idris, it's rather small but very 
nice and interesting.

Re: DIP87: Enhanced Foreign-Language Binding

[Rikki Cattermole via Digitalmars-d]

On 21/01/16 5:21 PM, Anon wrote:

Seeing the recent extern(C++) threads, and much concern therein, I'd
like to propose DIP87: http://wiki.dlang.org/DIP87

Destroy to your heart's content.


It was great until I saw:
extern(auto, "myMoveTo:")

After all:
extern(C/C++/D/Objective-C[, string])

Is that string meant for raw mangling or effect mangling in the form of 
selector?


Just no, leave @selector alone I think.

You have the same problem with c++ namespaces.

Perhaps this is slightly wrong.
extern(string)
Is the only way to force a specific mangling.

Where as
extern(C/C++/D/Objective-C[, string])
with the string altering in C++ and Objective-C mode.

So the only difference is extern(string) vs pragma(mangle, string)
Little harder sell, but I think might be worth it for cleaning up the 
language.

Re: D Article: Memory Safety

[Basile B. via Digitalmars-d-announce]

On Thursday, 21 January 2016 at 04:59:01 UTC, Basile B. wrote:
On Wednesday, 20 January 2016 at 14:04:53 UTC, Jakob Ovrum 
wrote:
The article aims to explain how to use @safe, @system and 
importantly, @trusted, including all the hairy details of 
templates.


https://jakobovrum.github.io/d/2016/01/20/memory-safety.html

Any and all feedback appreciated.


Good work. Someone has to re-edit-it if not yet reeddited.

Altgough one thing, attributes are not the easy part of D. I've 
recently encountered a case were in the library attributes were 
allright, test OK, and then suddently when I've started to use 
the library in a real life context I had to remove them from 
the library...@safe was unsustainable.


Dealing with attributes is the hardest part of D IMO.
No one is forced to btw, there are plenty of other cool things 
in D but to follow the D safety is hard...


congrats nice article.


I mean '@safe' at too low level is a handicap. It's like 'const'. 
They are hard to use, mostly because of transitivness. These 
attributes are never a noop.

Re: Walter on his experience as a dev, on running an open source project and D

[epsilomish via Digitalmars-d-announce]

On Wednesday, 20 January 2016 at 21:38:55 UTC, Walter Bright 
wrote:

On 1/20/2016 12:41 PM, epsilomish wrote:
Actually, the 'alias this' is probably not that much a 
problem. In their shoes I
would even ask myself: mmh what is this obscure feature, let's 
have a deeper
look to D...Anyway the technical part of the talk is small, 
there is the thing
about lexical D t_h_i_n_g_s, the octal template and 
half-floats...It globally

works.


I wanted a mix of trivial and advanced stuff, so there was 
something for everyone.


That's well reflected, despite of my first comment.

One thing I'd like to say in reaction the first part: noise and 
fan.
Personally I can't live without noise anymore. I used to be 
obsessional about silence but now I think it's very relaxing to 
have a fan turning again and again, by fan I mean:


http://www.cinni.com.au/images/pedestalFans.jpg

They produce a LF vibe which is very relaxing. For example now, 
here, where I live:


https://www.google.fr/maps/@48.5591464,7.7793422,9z?hl=fr

It's 21.2 F° outside, but I still have the good vibes from the 
low frequency generator in my computer room. a steady purr.

Re: extern(C++, ns)

[Anon via Digitalmars-d]

On Thursday, 21 January 2016 at 01:37:12 UTC, Walter Bright wrote:

On 1/20/2016 4:51 PM, Anon wrote:
What would you all say to the following proposal (and should I 
make a DIP?)


DIPs are always welcome.


Done.

http://forum.dlang.org/post/ldtluvnhuznvbebcb...@forum.dlang.org

DIP87: Enhanced Foreign-Language Binding

[Anon via Digitalmars-d]

Seeing the recent extern(C++) threads, and much concern therein, 
I'd like to propose DIP87: http://wiki.dlang.org/DIP87


Destroy to your heart's content.

Re: D Article: Memory Safety

[Jakob Ovrum via Digitalmars-d-announce]

On Wednesday, 20 January 2016 at 15:28:05 UTC, jmh530 wrote:
I like the description of @trusted and template inference. 
Template inference, in particular, was not something that was 
obvious to me when first reading about D. I'm not sure how 
clear you make it that you can still mark templates @safe and 
what have you (you seem to just say don't make templates 
@trusted).


Templated functions can still be explicitly annotated with 
attributes, which disables inference for those attributes. This 
is often a good idea even for templated functions when template 
arguments do not inject code, so that every instantiation has the 
same, known set of attributes. Attribute inference can handle it, 
but explicit annotations provide documentation value. I might 
incorporate this into the article, but I'm wary of it losing 
focus.


I wasn't aware of the point that "@trusted nested functions in 
templated functions do not have to have a memory safe interface 
as long as all calls to the function are memory safe". 
Interesting.


It is a necessary evil to propagate attributes correctly. Don't 
use it when you don't have to.

Re: D Article: Memory Safety

[Basile B. via Digitalmars-d-announce]

On Wednesday, 20 January 2016 at 14:04:53 UTC, Jakob Ovrum wrote:
The article aims to explain how to use @safe, @system and 
importantly, @trusted, including all the hairy details of 
templates.


https://jakobovrum.github.io/d/2016/01/20/memory-safety.html

Any and all feedback appreciated.


Good work. Someone has to re-edit-it if not yet reeddited.

Altgough one thing, attributes are not the easy part of D. I've 
recently encountered a case were in the library attributes were 
allright, test OK, and then suddently when I've started to use 
the library in a real life context I had to remove them from the 
library...@safe was unsustainable.


Dealing with attributes is the hardest part of D IMO.
No one is forced to btw, there are plenty of other cool things in 
D but to follow the D safety is hard...


congrats nice article.

Re: DIP87: Enhanced Foreign-Language Binding

[Anon via Digitalmars-d]

On Thursday, 21 January 2016 at 04:42:00 UTC, Rikki Cattermole 
wrote:

On 21/01/16 5:21 PM, Anon wrote:
Seeing the recent extern(C++) threads, and much concern 
therein, I'd

like to propose DIP87: http://wiki.dlang.org/DIP87

Destroy to your heart's content.


It was great until I saw:
extern(auto, "myMoveTo:")

After all:
extern(C/C++/D/Objective-C[, string])

Is that string meant for raw mangling or effect mangling in the 
form of selector?


Just no, leave @selector alone I think.


I don't know ObjC, so I had to wing it on the details there. The 
strings in
extern(, "str") would get sent through Foo's mangler. For 
ObjC, I currently imagine those strings forming the selector, 
much the same way it is specified through @selector. That ObjC's 
mangling mostly consists of 's/:/_/g' is irrelevant. I want *all* 
language binding to happen with a uniform interface. No more 
one-off hacks for a particular language (which is exactly what 
extern(C++,ns) and @selector are).




You have the same problem with c++ namespaces.


I don't see a problem. You'll have to be more specific.



Perhaps this is slightly wrong.
extern(string)
Is the only way to force a specific mangling.


There is no extern(string) in this proposal, nor is there a way 
to force a specific mangling, which (AFAIK) was only introduced 
to allow linking to C symbols that happened to be keywords.




Where as extern(C/C++/D/Objective-C[, string])
with the string altering in C++ and Objective-C mode.


It mangles regardless. Any and all of the extern() modes 
mangle. That C's mangling is to just return the input string is 
irrelevant.



So the only difference is extern(string) vs pragma(mangle, 
string)
Little harder sell, but I think might be worth it for cleaning 
up the language.


The difference is that it can mangle symbols correctly, even if 
the symbol is a D keyword.


Currently:

extern(C++) pragma(mangle, "delegate") int delegate_();

...yields a mangled name of "delegate", and there is no way to 
get the compiler to mangle the symbol correctly. Meaning you have 
to (ab)use pragma(mangle) and provide it with the full mangled 
name yourself. And `version()` it appropriately to deal with 
gcc/clang vs MSVC/DMC mangling.


With this DIP:

extern(C++, "delegate") int delegate_();

... would yield a mangled name of "_Z8delegatev" (or similar).

I thought I did a good enough job of explaining that in the DIP 
so I wouldn't have to here.

Re: So... add maxCount and maxPos?

[Andrei Alexandrescu via Digitalmars-d]

On 01/20/2016 04:22 PM, Ivan Kazmenko wrote:

On Wednesday, 20 January 2016 at 17:16:00 UTC, Andrei Alexandrescu wrote:

This is one of those cases in which we were pedantically right to not
add them, but their equivalents look like crap.

https://github.com/D-Programming-Language/phobos/pull/3942


As it seems related, let me share my personal experience with minPos.
Most of the time, I want one of the two things related to an extremum.

1. The minimum or maximum element itself.  I write it as
a.minPos.front.  That's almost fine, but maybe there is a more
expressive way?


Sadly, no. I'm very willing to add an overload of min and max for one 
argument (which fortunately does not compile currently) to compute these 
over a range. In fact literally today I wrote r.min and was surprised it 
didn't work. Would you want to embark on that? Code, docs, unittests, 
the works.



2. The index of minimum or maximum element, mostly using plain array as
a range.  I write "a.length - a.minPos.length", and it looks completely
unintuitive.  Additionally, when compiling to 64 bits, I usually still
want an int to use with other ints around (longs are overkill most of
the time), and the cast adds more clobber.  Again, is there a better way
to express that?


No better way currently. We could add (min|max)Index but I like 
(min|max)Pos quite a bit. They offer more flexibility for non-random 
access ranges. For random access ranges you should soon be able to write 
a.before(a.minPos).length, for a different kind of unintuitiveness :o).



Andrei

Re: D Article: Memory Safety

[H. S. Teoh via Digitalmars-d-announce]

On Thu, Jan 21, 2016 at 05:09:48AM +, Basile B. via Digitalmars-d-announce 
wrote:
[...]
> I mean '@safe' at too low level is a handicap. It's like 'const'. They
> are hard to use, mostly because of transitivness. These attributes are
> never a noop.

Transitivity also makes const really painful to use in a widespread way.
I've tried writing const-correct code before too, but gave up because it
quickly became too unwieldy to work with. I started spending more time
hunting down missing const attributes than actually writing useful code,
so I decided it was time to give up.

Generally, though, const is still useful in lower-level code (i.e., near
the leaf nodes of your function call tree), to prevent silly mistakes.
Knowing how to use const is also helpful in utility functions that need
to accept both immutable and mutable, etc.. Just like with (the current
state of) @safe, though, pervasive use of const is still too onerous
currently. Transitivity really makes it painful, especially when
important chunks of Phobos still isn't fully const-correct (or at least
const-compatible) yet. A lot of progress has been made, but, const being
transitive, all it takes is for one small Phobos function to be
non-const when it should be const, and your entire call tree can no
longer be const. Encounter this a handful of times, and it's hard not to
just throw in the towel instead of spending all of your time working
around const issues rather than writing useful code.

(Recently I'm slowly moving towards writing *all* my code as template
functions, and letting the compiler do the tedious work of attributing
my code instead of typing them out myself. My secret wish is that one
day, the compiler's attribute inference will be good enough that I could
just slap one or two const's (or @safe, etc.) on top of my modules and
everything will Just Work.)


T

-- 
Only boring people get bored. -- JM

Re: D Article: Memory Safety

[rsw0x via Digitalmars-d-announce]

On Wednesday, 20 January 2016 at 14:04:53 UTC, Jakob Ovrum wrote:
The article aims to explain how to use @safe, @system and 
importantly, @trusted, including all the hairy details of 
templates.


https://jakobovrum.github.io/d/2016/01/20/memory-safety.html

Any and all feedback appreciated.


my experience with @safe:

okay, I'll just use @safe here... and nothing else in third party 
libraries/half of phobos is @safe friendly so I guess I'll wrap 
it in @trusted oh fuck it

Re: [dlang.org] new forum design

[Vladimir Panteleev via Digitalmars-d]

On Wednesday, 20 January 2016 at 19:04:18 UTC, Jacob Carlborg 
wrote:

On 2016-01-19 20:59, Vladimir Panteleev wrote:


Yep, plus now that we use a narrow font :P

Made it narrower + hid it on very narrow viewports (incl. 
portrait iPhone).


Thanks. But now when the column is removed, it's not enough 
margin/padding on the right side, for the "Last Post" column.


Sorry, I don't understand. I don't see a problem in the iOS 
simulator in neither portrait or landscape mode. Can you 
elaborate or post a screenshot?

Re: Compile-Time RNG

[tsbockman via Digitalmars-d]

On Thursday, 21 January 2016 at 01:49:27 UTC, Timon Gehr wrote:
It only works because compile-time introspection is ill-defined 
though. I don't expect it to keep working indefinitely.


That aspect can easily be replaced by __LINE__ and __FILE__.

Re: D Article: Memory Safety

[Jakob Ovrum via Digitalmars-d-announce]

On Thursday, 21 January 2016 at 06:20:01 UTC, rsw0x wrote:
okay, I'll just use @safe here... and nothing else in third 
party libraries/half of phobos is @safe friendly so I guess 
I'll wrap it in @trusted oh fuck it


Yeah, using @trusted like that is counterproductive. Just use 
@system or improve the dependencies.

Re: DIP87: Enhanced Foreign-Language Binding

[deadalnix via Digitalmars-d]

On Thursday, 21 January 2016 at 04:21:06 UTC, Anon wrote:
Seeing the recent extern(C++) threads, and much concern 
therein, I'd like to propose DIP87: http://wiki.dlang.org/DIP87


Destroy to your heart's content.


This propose to change everything while not even providing 
anything more than what we already have.


If it was to start from scratch, why not, but clearly, in its 
current shape, this doesn't pay for itself.

Re: extern(C++, ns)

[Anon via Digitalmars-d]

What would you all say to the following proposal (and should I 
make a DIP?)



1. deprecate pragma(mangle)
2. deprecate extern(C++, ns)
3. deprecate @selector()
4. Introduce a better, more general extern() as follows:

extern (  [,  ] )

Which would *only* influence mangling and calling conventions. 
Blocks would concatenate their s, with the default value 
for a symbol being its identifier. Whatever the concatenated 
string is then gets run through a language-specific mangler with 
knowledge of the type info. It would be an error for nesting 
blocks to change language. The content of the string would depend 
on the language in question. This would be also extendable beyond 
C, C++, D, and Objective-C to other languages if so desired 
(Rust, Go, C#, etc.) while keeping a uniform syntax and behavior 
regardless of the language being bound.


Some examples:

extern(C) int foo(); // Mangled as "foo"

extern(C, "body") int body_(); // "body"

extern(C++) int foo(); // cppMangleOf("foo")

extern(C++, "body") int body_(); // cppMangleOf("body")

extern(D) int foo(); // "_D3fooFZi" -no module

extern(D, "body") int body_; // "_D4bodyFZi" -no module

extern(C++, "ns::foo") int foo(); // cppMangleOf("ns::foo")

extern(C++, "ns::")
{
int foo(); // cppMangleOf("ns::foo")

extern(C++, "body") int body_(); // cppMangleOf("ns::body")

// I'm unsure of the next two. Both need to be inside an
// extern() block and would infer the 
// extern("with") int with_(); // cppMangleOf("ns::with")
// extern(auto, "with") int with_(); // 
cppMangleOf("ns::with")

}

extern(C, "SDL_")
{
void init(); // "SDL_init"
}

extern(D, "std.ascii.")
{
// std.ascii.isAlphaNum.mangleof
bool isAlphaNum(dchar) pure nothrow @nogc @safe bool;
}

Re: extern(C++, ns)

[David Nadlinger via Digitalmars-d]

On Wednesday, 20 January 2016 at 23:21:49 UTC, Walter Bright 
wrote:

On 1/20/2016 3:12 PM, Martin Drašar via Digitalmars-d wrote:

The "serious" problem is
that the decision to have a namespace introduce a new scope 
needlessly
complicates writing D-like interfaces to C++ code, while 
catering for

one specific use-case that is considered niche.


Adding a qualifier here and there does not count as serious.


But, to put this statement in the context of my other post, it 
further raises the bar which the arguments in favor of having 
extern(C++) introduce D-side scopes have to clear. If we had 
extern(C++, "ns") just affect the mangling, the need for adding 
extra qualifiers wouldn't exist in the first place.


 — David

[Issue 15507] Throwable.message() should be pure @safe

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15507

Dicebot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Dicebot  ---
As actual addition has been reverted for now, the issue has become
unapplicable.

--

Re: Compile-Time RNG

[Brian Schott via Digitalmars-d]

On Wednesday, 20 January 2016 at 23:21:04 UTC, CTRNG wrote:

I managed to create a compile-time random number generator.

Proof of concept, with some explanatory comments: 
http://dpaste.dzfl.pl/668646ce6d71


Just thought this might be of interest to some of you here.


That's nearly as fun as using the bsr and bsf functions in 
core.bitop to implement a pure random number generator.


https://issues.dlang.org/show_bug.cgi?id=14380

Re: D Article: Memory Safety

[default0 via Digitalmars-d-announce]

On Wednesday, 20 January 2016 at 14:04:53 UTC, Jakob Ovrum wrote:
The article aims to explain how to use @safe, @system and 
importantly, @trusted, including all the hairy details of 
templates.


https://jakobovrum.github.io/d/2016/01/20/memory-safety.html

Any and all feedback appreciated.


Nice article! Feeling like I have a much better grasp on the 
whole attribute system now that I read it, thanks! :-)

Re: topN using a heap

[Andrei Alexandrescu via Digitalmars-d]

On 01/19/2016 08:08 PM, Ivan Kazmenko wrote:

On Tuesday, 19 January 2016 at 13:52:08 UTC, Andrei Alexandrescu wrote:

On 01/18/2016 09:21 PM, Ivan Kazmenko wrote:
Do you think sort and topN would be attackable if they used a
per-process-seeded RNG as per Xinok's idea? -- Andrei


Yes, but with a little interactivity (not generating the input in
advance) and more labor (finding the state of RNG).

[snip]

Thanks! -- Andrei

Re: So... add maxCount and maxPos?

[H. S. Teoh via Digitalmars-d]

On Wed, Jan 20, 2016 at 12:16:00PM -0500, Andrei Alexandrescu via Digitalmars-d 
wrote:
> This is one of those cases in which we were pedantically right to not
> add them, but their equivalents look like crap.
> 
> https://github.com/D-Programming-Language/phobos/pull/3942
[...]

I don't like this.  I'd much rather we rename those functions to be
something more generic.  After all, minPos is a horrible name when the
predicate has nothing to do with minimum values. What about extremumPos?
(Though that's rather ugly to type.)


T

-- 
People demand freedom of speech to make up for the freedom of thought which 
they avoid. -- Soren Aabye Kierkegaard (1813-1855)

Re: medianOfMedians

[Andrei Alexandrescu via Digitalmars-d]

On 01/19/2016 09:26 PM, Timon Gehr wrote:

On 01/20/2016 02:20 AM, Andrei Alexandrescu wrote:

I've seldom have code write itself so beautifully. Which, of course,
means it needs to be destroyed.
https://github.com/D-Programming-Language/phobos/pull/3938 -- Andrei


This is not an implementation of the median of medians algorithm.

[snip]

Thanks again for sharing your insight. FWIW there's a bit of variation 
floating on the Net regarding MoM. The Wikipedia article at 
https://en.wikipedia.org/wiki/Median_of_medians moves the medians of 
five to the beginning of the array (my implementation uses stride(), 
thus trading computation for data movement). I'm unclear on which 
approach is generally better.


http://austinrochford.com/posts/2013-10-28-median-of-medians.html does 
not mention the mutual recursion, suggesting (at least in a cursory 
reading) my wishy-washy previous implementation that doesn't use 
quickselect.


https://www.ics.uci.edu/~eppstein/161/960130.html only uses one 
recursive function, not two.


The original PICK algorithm at 
https://people.csail.mit.edu/rivest/pubs/BFPRT73.pdf only uses one 
recursive function.


Anyhow, I've implemented the two-functions version at 
https://github.com/D-Programming-Language/phobos/pull/3938. I'll next 
try whether the one-function version is just as good or better. Destroy?



Andrei

Re: D and CLion

[Rikki Cattermole via Digitalmars-d]

On 21/01/16 5:40 AM, Russel Winder via Digitalmars-d wrote:

Kingsley is developing a D plugin for IntelliJ IDEA – which is a Good
Thing™.

However, as I have said before, I think CLion (a C++ IDE, where
IntelliJ IDEA is really a JVM languages IDE) would be a far better
place for D to be supported.

Given CLion is CMake based, CMake-D is important to getting things
moving initially. We can worry about Dub support and dependency
management along the way.

I have created an issue with the JetBrains tracker for this enhancement
request.

https://youtrack.jetbrains.com/issue/CPP-5648

IntelliJ IDEA already supports Gradle as a project driver so the idea
of CLion allowing Dub to be a project driver is not outwith the bounds
of possibility.

It would be nice if we could develop plugins in Kotlin rather than
Java!


Intellij IDEA is the base IDE.
The branded ones like CLion are just it plus some propriety plugins.

But yes having them play nicely with each other is definitely preferable.

Re: Distribution of D apps

[Rikki Cattermole via Digitalmars-d-learn]

On 21/01/16 5:01 AM, Dibyendu Majumdar wrote:

Hi,

I am trying to understand the options for distributing a D app to users.
My assumption is that only the shared libraries and binaries need to be
distributed, and I need to include the D libraries. Is this correct?

Thanks and Regards
Dibyendu


Binaries such as such as shared libraries do indeed need to be packaged 
in the distribution.


Static library files do not need to be distributed however.

So... add maxCount and maxPos?

[Andrei Alexandrescu via Digitalmars-d]

This is one of those cases in which we were pedantically right to not 
add them, but their equivalents look like crap.


https://github.com/D-Programming-Language/phobos/pull/3942


Andrei

opIndex, opSlice, length for joiner?

[Maverick Chardet via Digitalmars-d]

Hi everyone,

After reading the thread "Distributed Memory implementation": 
http://forum.dlang.org/post/oqcfifzolmolcvyup...@forum.dlang.org


And more precisely the suggestion of Dragos Carp on page 2: 
http://forum.dlang.org/post/txgabyyoutitketlp...@forum.dlang.org


I looked at the joiner source code 
(std.algorithm.iteration.joiner) and I have several ideas to make 
it have the opIndex, opSlice and length methods under certain 
conditions.


First question: what do you think of making this possible if all 
the considered ranges have opIndex, opSlice and length? I think 
that all the ranges types don't have to all implement the three 
methods in all cases (for instance length would actually only 
require ElementType!RoR and Separator to implement length) but we 
can discuss all that later...


The most important issue that comes to my mind is that the 
operations would not take constant time... A trivial 
implementation would be in O(k) where k is the number of joined 
ranges, and with some precomputation in O(k) time and space we 
can make length O(1) and opIndex and opSlice O(log k)... Would 
that be a problem?


Thank you in advance for your remarks!

Re: mystery crashes

[H. S. Teoh via Digitalmars-d]

On Tue, Jan 19, 2016 at 04:00:32PM -0800, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Jan 19, 2016 at 10:19:22PM +, tsbockman via Digitalmars-d wrote:
> > Could I persuade someone from the compiler team to take a look at
> > this bug report I filed?
> > https://issues.dlang.org/show_bug.cgi?id=15573
[...]
> I took a look, and couldn't reproduce the problem (Linux/x86_64). As I
> said in the bug comments, this looks like the symptoms of the compiler
> picking up the wrong version of a library (either druntime or phobos
> or other 3rd party libraries), or stale object files in your build
> cache.
[...]

I take that back; we've found that it was caused by a bad interaction
between -O and -inline in dmd that triggers a codegen bug, in which the
edx register was not properly initialized prior to the idiv instruction,
causing the result of the integer division to be garbage.

Maybe one of the compiler devs (probably Walter, as this may be backend
related) could look at this?


T

-- 
I am not young enough to know everything. -- Oscar Wilde

[Issue 15573] -O -inline causes wrong code with idiv instruction

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15573

--- Comment #24 from hst...@quickfur.ath.cx ---
Maybe related?: https://issues.dlang.org/show_bug.cgi?id=10540

--

Distribution of D apps

[Dibyendu Majumdar via Digitalmars-d-learn]

Hi,

I am trying to understand the options for distributing a D app to 
users. My assumption is that only the shared libraries and 
binaries need to be distributed, and I need to include the D 
libraries. Is this correct?


Thanks and Regards
Dibyendu

[Issue 15513] Memory Corruption with thread local objects

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15513

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #5 from ag0ae...@gmail.com ---
Reduced this some:

foo.d:

import std.stdio: writeln;
import core.thread: Thread;

void main() {
  writeln("Start frop from D");
  frop();
}

extern(C) void function() startup_routine = 

extern(C) void initialize() {
  import core.runtime;  
  Runtime.initialize;
  writeln("Start frop from C");
  frop();
  Runtime.terminate();
}

void frop() {
  Thread bar = new Thread();
  bar.start();
  bar.join();
}

void foo() {
  proc();
  new int;
  new int[10_000];
  writeln(dash);
}

int[] dash;

void proc () {
  dash.length = 8;
  dash[] = 0;
}


main.c:

#include 

typedef void (*routine_t)(void);

int main(int argc, char*argv[]) {
  void* dll = dlopen("./foo.so", RTLD_LAZY);
  routine_t* routine = (routine_t*)dlsym(dll, "startup_routine");
  (*routine)();
}


Compile and run:

dmd foo.d && ./foo

# change the path for the -L-R option according to your setup
dmd -fPIC -shared -offoo.so -L-ldl -L-lphobos2 -L-R$HOME/d/dmd2.git/linux/lib64
foo.d
gcc -m64 -fPIC main.c -ldl -o main
./main


Output:

Start frop from D
[0, 0, 0, 0, 0, 0, 0, 0]
Start frop from C
[-1488654016, 32761, 37363216, 0, 0, 0, 0, 0]


--

Re: How to know if opSlice is defined for a type (including built-in types)?

[chardetm via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 15:25:10 UTC, Jonathan M Davis 
wrote:
On Wednesday, January 20, 2016 13:06:00 chardetm via 
Digitalmars-d-learn wrote:
Anyone who has the same problem: I found 
std.range.primitives.hasSlicing 
(https://dlang.org/phobos/std_range_primitives.html#hasSlicing) which does exactly what I want!


Note that because strings are treated as ranges of dchar 
regardless of what their actual character type is, arrays of 
char and wchar (so-called "narrow" strings) are not consider to 
have slicing or random access by the traits in std.range. So, 
hasSlicing!string is false, though for anything other than an 
array of char or wchar, it will do what you're looking for, 
whereas for arrays of char or wchar, you really shouldn't be 
using the slice operator on them without knowing that they're 
what you're operating on so that you take the Unicode issues 
into account correctly.


- Jonathan M Davis


Yes and that was the next step of my problem, it turned out that 
it was already taken into account by hasSlicing!


Thank you very much!

Re: extern(C++, ns)

[Simen Kjaeraas via Digitalmars-d]

On Wednesday, 20 January 2016 at 12:47:44 UTC, Manu wrote:

2. Multiple modules cannot have the same name in D.



I'm not sure what situation you're imagining where modules 
would be created with the same names...?




How do you plan to map C++'s standard lib ? One giant hundred 
of thousands of line C++ file ?


Surely it would map by file.

#include  -> import stl.vector;
#include  -> import stl.map;
#include  -> import stl.string;

Perhaps 'stl' may be something else, 'std' is an unfortunate 
conflict with phobos, but this is unique to this case.


I believe deadalnix here meant something like this:

  import stl.vector;
  import mylib.vector;

  Vector a; // Ambiguous: could be from mylib or stl
  stl.Vector b; // Error: no such class stl.Vector
  stl.vector.Vector c; // Works, but requires extra typing

Which with working namespaces might allow case b to work.

--
  Simen

[Issue 15513] Memory Corruption with thread local objects

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15513

--- Comment #4 from Puneet Goel  ---
Created attachment 1577
  --> https://issues.dlang.org/attachment.cgi?id=1577=edit
Another testcase with just one thread

--

D and CLion

[Russel Winder via Digitalmars-d]

Kingsley is developing a D plugin for IntelliJ IDEA – which is a Good
Thing™.

However, as I have said before, I think CLion (a C++ IDE, where
IntelliJ IDEA is really a JVM languages IDE) would be a far better
place for D to be supported.

Given CLion is CMake based, CMake-D is important to getting things
moving initially. We can worry about Dub support and dependency
management along the way.

I have created an issue with the JetBrains tracker for this enhancement
request.

https://youtrack.jetbrains.com/issue/CPP-5648

IntelliJ IDEA already supports Gradle as a project driver so the idea
of CLion allowing Dub to be a project driver is not outwith the bounds
of possibility.

It would be nice if we could develop plugins in Kotlin rather than
Java!
 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

[Issue 15513] Memory Corruption with thread local objects

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15513

--- Comment #3 from Puneet Goel  ---
Adding another test case. This time I could replicate the issue within a single
thread.

Testcase has been attached.

This issue has also been discussed in the forum thread
http://forum.dlang.org/thread/yjywwllcsslgotgrf...@forum.dlang.org

--

Re: opIndex, opSlice, length for joiner?

[Ilya via Digitalmars-d]

On Wednesday, 20 January 2016 at 17:36:29 UTC, Maverick Chardet 
wrote:

Hi everyone,

After reading the thread "Distributed Memory implementation": 
http://forum.dlang.org/post/oqcfifzolmolcvyup...@forum.dlang.org


And more precisely the suggestion of Dragos Carp on page 2: 
http://forum.dlang.org/post/txgabyyoutitketlp...@forum.dlang.org


I looked at the joiner source code 
(std.algorithm.iteration.joiner) and I have several ideas to 
make it have the opIndex, opSlice and length methods under 
certain conditions.


First question: what do you think of making this possible if 
all the considered ranges have opIndex, opSlice and length? I 
think that all the ranges types don't have to all implement the 
three methods in all cases (for instance length would actually 
only require ElementType!RoR and Separator to implement length) 
but we can discuss all that later...


The most important issue that comes to my mind is that the 
operations would not take constant time... A trivial 
implementation would be in O(k) where k is the number of joined 
ranges, and with some precomputation in O(k) time and space we 
can make length O(1) and opIndex and opSlice O(log k)... Would 
that be a problem?


Thank you in advance for your remarks!


O(K) looks OK for joiner. However this will cause additional 
performance problem because a couple of Phobos algorithm assumes 
that opIndex is fast as front+popFront. Perhaps a special UDA can 
be introduced, something like @optimized("forward range").


See also `byElement` for multidimensional random access slices. 
It has opIndex and slicing.

https://github.com/D-Programming-Language/phobos/blob/v2.070.0-b2/std/experimental/ndslice/selection.d#L893

Ilya

Re: Mixin Template Function Attributes

[Marc Schütz via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 16:37:31 UTC, jmh530 wrote:
I'm not sure if this is how the behavior is supposed to be or 
if it is a bug.


I believe, however, that it _is_ a bug that the imported symbols 
are visible outside the template. Most likely related to the 
infamous https://issues.dlang.org/show_bug.cgi?id=314

Re: Mixin Template Function Attributes

[Marc Schütz via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 16:37:31 UTC, jmh530 wrote:
I'm not sure if this is how the behavior is supposed to be or 
if it is a bug.


It's not a bug. The `@attribute:` syntax applies to all following 
declarations _inside the current scope_, i.e. until your mixin 
templates closing `}`.

[Issue 15573] -O -inline causes wrong code with idiv instruction

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15573

--- Comment #25 from thomas.bock...@gmail.com ---
The similar crashes I was getting with LDC turn out to be unrelated to this
issue, despite the similar symptoms:
https://issues.dlang.org/show_bug.cgi?id=15586
(It's a bug in Phobos, which I have already submitted a PR for.)

--

Re: Mixin Template Function Attributes

[jmh530 via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 19:19:04 UTC, Marc Schütz wrote:

On Wednesday, 20 January 2016 at 16:37:31 UTC, jmh530 wrote:
I'm not sure if this is how the behavior is supposed to be or 
if it is a bug.


I believe, however, that it _is_ a bug that the imported 
symbols are visible outside the template. Most likely related 
to the infamous https://issues.dlang.org/show_bug.cgi?id=314


Thanks. The fact that one worked and the other didn't was what I 
found weird.

Re: extern(C++, ns)

[Marc Schütz via Digitalmars-d]

On Wednesday, 20 January 2016 at 17:25:56 UTC, JohnCK wrote:
On Wednesday, 20 January 2016 at 16:38:19 UTC, Marc Schütz 
wrote:

I think the first error is correct:

bar();  // Error: b.bar at b.d(6) conflicts with 
a.ns.bar at a.d(5)




Yes, I put this one in to show why the next lines are sometimes 
necessary.


So you have two functions bar() one inside 'ns' in module a and 
"outside" 'ns' in module b.


Now, the last 2 errors, Mark Schutz said:

a.ns.bar(); // works, but requires superfluous `a`, even 
though

// `ns` already makes it unambiguous


Question: What happens if you do this: using "ns1" in "module 
a" and "ns2" in "module b" and do:


ns1.bar();

?


There'd be no collision anymore, but...



Because you can't have more than one namespaces with the same 
name in C++, right?


You can:

namespace ns {
void foo();
}
namespace ns {
void bar();
}
int main() {
ns::bar();
return 0;
}

More realistically, the namespace declarations would appear in 
different header files, all #included into the same cpp file. 
These different header files would naturally be mapped to 
different D modules.

Re: So... add maxCount and maxPos?

[Andrei Alexandrescu via Digitalmars-d]

On 01/20/2016 12:29 PM, H. S. Teoh via Digitalmars-d wrote:

On Wed, Jan 20, 2016 at 12:16:00PM -0500, Andrei Alexandrescu via Digitalmars-d 
wrote:

This is one of those cases in which we were pedantically right to not
add them, but their equivalents look like crap.

https://github.com/D-Programming-Language/phobos/pull/3942

[...]

I don't like this.  I'd much rather we rename those functions to be
something more generic.  After all, minPos is a horrible name when the
predicate has nothing to do with minimum values. What about extremumPos?
(Though that's rather ugly to type.)


extremumPos has been on my wish list for a while now, but (a) we're 
stuck with minPos anyway, (b) extremumPos sounds elitist. -- Andrei

[Issue 15586] New: std.utf.toUTF8() segfaults when fed an invalid dchar

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15586

  Issue ID: 15586
   Summary: std.utf.toUTF8() segfaults when fed an invalid dchar
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: thomas.bock...@gmail.com

Repro:

void main()
{
import std.utf : toUTF8;
char[4] buf = void;
auto b = toUTF8(buf, cast(dchar)0x11);

import std.stdio;
writeln(b);
}

Cause:

toUTF8() asserts that invalid dchars just *don't exist*. It then proceeds to
return *nothing at all* when fed one, which violates memory safety.

Because of https://issues.dlang.org/show_bug.cgi?id=15585 the compiler may
optimize away attempts to fix this entirely.

--

Re: So... add maxCount and maxPos?

[H. S. Teoh via Digitalmars-d]

On Wed, Jan 20, 2016 at 02:30:10PM -0500, Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 01/20/2016 12:29 PM, H. S. Teoh via Digitalmars-d wrote:
> >On Wed, Jan 20, 2016 at 12:16:00PM -0500, Andrei Alexandrescu via 
> >Digitalmars-d wrote:
> >>This is one of those cases in which we were pedantically right to
> >>not add them, but their equivalents look like crap.
> >>
> >>https://github.com/D-Programming-Language/phobos/pull/3942
> >[...]
> >
> >I don't like this.  I'd much rather we rename those functions to be
> >something more generic.  After all, minPos is a horrible name when
> >the predicate has nothing to do with minimum values. What about
> >extremumPos?  (Though that's rather ugly to type.)
> 
> extremumPos has been on my wish list for a while now, but (a) we're
> stuck with minPos anyway, (b) extremumPos sounds elitist. -- Andrei

If renaming is out of the question, then I suppose maxPos/maxCount would
be the next less evil. :-P  If we ever get to D3, this would be one of
the things that should be changed... but until then, I guess we can live
with maxPos/maxCount.


T

-- 
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG

Should std.range.primitives.ElementType have sig constraints?

[H. S. Teoh via Digitalmars-d]

Currently, std.range.primitives.ElementType has no sig constraints, so
it will pick up all sorts of things that aren't ranges.  This is not so
nice, because ranges aren't the only thing that have elements, and it
would be nice if such a good name as ElementType could be reused for
other user-defined generic constructs.

For example, I wrote some generic code for working with 2D scalar
fields (i.e., arbitrary objects that define opIndex(double,double)), and
defined an ElementType template specific to fields:

template ElementType(F)
if (is2DField!F)
{
alias ElementType = typeof(F.init[0.0, 0.0]);
}

However, this causes a conflict wherever I import std.range, since
std.range.primitives.ElementType matches *everything*, including 2D
field objects that have no resemblance whatsoever to ranges, only to
return `void`. Shouldn't ElementType be constrained to only those types
that it understands?

I dug through the git history, and it seems that ElementType has always
been defined this way, ever since Andrei first committed the
implementation of range primitives. The original docs did not mention
anything about picking up all types; that comment (part of the current
docs) was added much later by someone else.

What was the rationale for having no sig constraints for ElementType?
Was it an oversight? Doesn't seem like it, since it explicitly returns
`void` for non-range types. What's the purpose of that?  Would it be
acceptable to modify the definition of ElementType to:

template ElementType(R)
if (isInputRange!R)
{ ... }

?


T

-- 
Любишь кататься - люби и саночки возить. 

Re: [dlang.org] new forum design

[Jacob Carlborg via Digitalmars-d]

On 2016-01-19 20:59, Vladimir Panteleev wrote:


Yep, plus now that we use a narrow font :P

Made it narrower + hid it on very narrow viewports (incl. portrait iPhone).


Thanks. But now when the column is removed, it's not enough 
margin/padding on the right side, for the "Last Post" column.


--
/Jacob Carlborg

[Issue 15585] New: VRP incorrectly assumes that out-of-range dchar values don't exist

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15585

  Issue ID: 15585
   Summary: VRP incorrectly assumes that out-of-range dchar values
don't exist
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: thomas.bock...@gmail.com

This issue doesn't currently have much in the way of visible symptoms, but it
will as VRP gets smarter in other ways:
https://github.com/D-Programming-Language/dmd/pull/5229

Fixing this was been pre-approved by Walter Bright on the forums (although
there are other aspects of the above PR which are still under review):
http://forum.dlang.org/post/oionrfexehapzicgp...@forum.dlang.org

--

Re: Mixin Template Function Attributes

[jmh530 via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 19:48:04 UTC, jmh530 wrote:
On Wednesday, 20 January 2016 at 19:19:04 UTC, Marc Schütz 
wrote:

On Wednesday, 20 January 2016 at 16:37:31 UTC, jmh530 wrote:
I'm not sure if this is how the behavior is supposed to be or 
if it is a bug.


I believe, however, that it _is_ a bug that the imported 
symbols are visible outside the template. Most likely related 
to the infamous https://issues.dlang.org/show_bug.cgi?id=314


Thanks. The fact that one worked and the other didn't was what 
I found weird.


It looks like this issue covers it
https://issues.dlang.org/show_bug.cgi?id=12735

It appears that there is a pull request in the works to fix the 
behavior.

Re: So... add maxCount and maxPos?

[Timon Gehr via Digitalmars-d]

On 01/20/2016 06:29 PM, H. S. Teoh via Digitalmars-d wrote:

On Wed, Jan 20, 2016 at 12:16:00PM -0500, Andrei Alexandrescu via Digitalmars-d 
wrote:

This is one of those cases in which we were pedantically right to not
add them, but their equivalents look like crap.

https://github.com/D-Programming-Language/phobos/pull/3942

[...]

I don't like this.  I'd much rather we rename those functions to be
something more generic.  After all, minPos is a horrible name when the
predicate has nothing to do with minimum values.


The predicate always describes an order relative to which to find a minimum.

JMH

[Andrei Alexandrescu via Digitalmars-d]

So this is available for Java: http://java-performance.info/jmh/. The 
framework uses attributes such as @Benchmark, 
@BenchmarkMode(Mode.AverageTime), @OutputTimeUnit(TimeUnit.MICROSECONDS) 
etc. to great effect. Far as I can imagine, runtime reflection is used.


We should do the same, just with compile-time reflection!


Andrei

[Issue 15586] std.utf.toUTF8() segfaults when fed an invalid dchar

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15586

--- Comment #1 from thomas.bock...@gmail.com ---
Fix for the Phobos bug:
https://github.com/D-Programming-Language/phobos/pull/3943
Fix for the DMD bug: https://github.com/D-Programming-Language/dmd/pull/5229

--

Re: Should std.range.primitives.ElementType have sig constraints?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 20 January 2016 at 18:54:34 UTC, H. S. Teoh wrote:
Currently, std.range.primitives.ElementType has no sig 
constraints, so it will pick up all sorts of things that aren't 
ranges.  This is not so nice, because ranges aren't the only 
thing that have elements, and it would be nice if such a good 
name as ElementType could be reused for other user-defined 
generic constructs.


For example, I wrote some generic code for working with 2D 
scalar
fields (i.e., arbitrary objects that define 
opIndex(double,double)), and

defined an ElementType template specific to fields:

template ElementType(F)
if (is2DField!F)
{
alias ElementType = typeof(F.init[0.0, 0.0]);
}

However, this causes a conflict wherever I import std.range, 
since std.range.primitives.ElementType matches *everything*, 
including 2D field objects that have no resemblance whatsoever 
to ranges, only to return `void`. Shouldn't ElementType be 
constrained to only those types that it understands?


I dug through the git history, and it seems that ElementType 
has always been defined this way, ever since Andrei first 
committed the implementation of range primitives. The original 
docs did not mention anything about picking up all types; that 
comment (part of the current docs) was added much later by 
someone else.


What was the rationale for having no sig constraints for 
ElementType? Was it an oversight? Doesn't seem like it, since 
it explicitly returns `void` for non-range types. What's the 
purpose of that?  Would it be acceptable to modify the 
definition of ElementType to:


template ElementType(R)
if (isInputRange!R)
{ ... }



I'm not sure that I'd consider it a good idea to reuse the name 
ElementType elsewhere given how pervasive 
std.range.primitives.ElementType is in code, but I don't see any 
reason why it shouldn't have a template constraint on it, and if 
it does, the module system would allow you to reuse the name. But 
even if we all agreed that reusing the name was a bad idea, the 
error messages when ElementType was misused would definitely be 
better if it had a template constraint no it.


So, I see no problem with adding a constraint.

- Jonathan M Davis

Re: JMH

[Robert burner Schadek via Digitalmars-d]

Yes, something like that would be nice. But as the website states 
you need to use maven to build the project that uses that library.


I can only suspect, but I think they use maven to collect all 
functions that use @Benchmark. And this leads to the problem the 
unittest library proposal for phobos had.


The problem was that the user had to create a custom main that 
listed all modules to check for tests or use a build tool with 
some globbing commands. Both not perfect.


""" Shameless self promoting ON """

With PR: 
https://github.com/D-Programming-Language/phobos/pull/2995


you can write:

```
void funToTest(string, int, float) {
// funToTest impl
}

unittest {
benchmark!funToTest();
}
```

and then you only have to pass the -unittest switch to dmd and be 
happy.


""" Shameless self promoting OFF """

[Issue 15587] Enable use of D keywords as identifiers when interfacing to C/C++

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15587

Walter Bright  changed:

   What|Removed |Added

   Keywords||C++

--

[Issue 15587] New: Enable use of D keywords as identifiers when interfacing to C/C++

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15587

  Issue ID: 15587
   Summary: Enable use of D keywords as identifiers when
interfacing to C/C++
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

Consider:

extern (C) int* with();

where delegate is a C function name. This, of course, fails because 'with' is a
D keyword. A solution is:

extern (C) int* with_();

and have the C/C++ name mangler remove any trailing _ from identifiers.

The prefix version, _with, has problems because it would be impossible to have
a C identifier named '_traits' or '_gshared'.

--

Re: opIndex, opSlice, length for joiner?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 20 January 2016 at 17:36:29 UTC, Maverick Chardet 
wrote:
The most important issue that comes to my mind is that the 
operations would not take constant time... A trivial 
implementation would be in O(k) where k is the number of joined 
ranges, and with some precomputation in O(k) time and space we 
can make length O(1) and opIndex and opSlice O(log k)... Would 
that be a problem?


The various range primitives all need to be O(1). We need to be 
able to rely on the big-o complexity of the primitives used by 
ranges, or the performance of various algorithms will tank when 
used with ranges that don't stick to the expected big-o 
complexities. So, if a range type cannot provide a primitive as 
O(1), it should not provide that primitive. If that weren't the 
case, then we'd have stuff like length, opIndex, and opSlice for 
narrow strings, but we don't.


std.container lists the algorithmic complexity for its various 
operations for the same reason, and as I understand it, its 
replacement that Andrei is working on is going to do the same.


- Jonathan M Davis

Idea: limited template expansion

[Steven Schveighoffer via Digitalmars-d]

I am writing some code for a library, and an interesting situation comes 
up. Let's say you have some code that can deal with wchar, dchar, or 
char arrays. You template the code based on the code unit type, but the 
input comes in as a file stream (which is bytes).


What I have been doing is this:

void foo(C)(C[] buf) {...}


ubyte[] buffer = ...;
switch(detectBOM(buffer))
{
  case UTF8:
 foo(cast(char[])buffer);
 break;
  case UTF16:
 foo(cast(wchar[])buffer);
 break;
  case UTF32:
 foo(cast(dchar[])buffer);
 break;
  default:
 assert(0);
}

Essentially, I'm wrapping a runtime check into a compile-time construct, 
but I have to always deal with this switch mechanism and a lot of boiler 
plate.


It would be cool if the compiler could "expand" a finitely instantiable 
template (one with a finite number of ways it can be instantiated) based 
on a runtime value, and do the switch for me.


Something like:

void foo(BOM b)(ubyte[] buffer) { ... /* cast to correct char type */ }

ubyte[] buffer = ...;
foo!(detectBOM(buffer))(buffer);

would expand into what I wrote manually. It may need a different syntax 
from template instantiation, since it does involve runtime checking.


Does this have any appeal to people? Any other use cases?

-Steve

[Issue 15586] std.utf.toUTF8() segfaults when fed an invalid dchar

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15586

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--- Comment #2 from hst...@quickfur.ath.cx ---
I don't understand something here.  The in-contract of toUTF8 asserts that the
dchar must be valid... but why does the assert not trigger at runtime (even in
spite of not compiling with -release).  This doesn't seem like a Phobos bug; it
seems to be a bug in the compiler for "optimizing" away the assert just because
it thinks that dchar's cannot have invalid values.

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10378

--- Comment #20 from Steven Schveighoffer  ---
(In reply to Ketmar Dark from comment #19)
> ah, i see, thank you. i really misread the suggesion. still, i like Kenji's
> PR4915 more. ;-) i'd better see "shadowing error", so i can simply rename
> symbols, and don't guess if there is conflict or not.

Yes, thank you Timon for explaining better.

The main reason I see local imports being useful is this:

import somemodule;

void foo()
{
   onlyPlaceSomeModuleIsUsed()
}

Now, one can simply say "wait, somemodule isn't something everyone in the file
needs, just foo. I'll move it inside"

And then it breaks. I'd rather just see it work the same. All you are doing is
saying who has access to somemodule's symbols, and avoid polluting the module
namespace.

--

[Issue 15585] VRP incorrectly assumes that out-of-range dchar values don't exist

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15585

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx
   Severity|normal  |critical

--- Comment #1 from hst...@quickfur.ath.cx ---
Actually, it *does* already cause a very visible, nasty problem:

https://issues.dlang.org/show_bug.cgi?id=15586

Basically, by assuming that dchar can never have invalid values (no matter
where the dchar came from), the compiler has basically turned all code
containing `cast(dchar)` into undefined behaviour, because it will optimize out
all character range checks (under its wrong assumption, none of the checks can
ever fail, since dchar can't possibly have invalid values). This means
string-vetting functions are basically turned to no-ops, and code that's
supposed to throw exceptions or assert errors upon invalid dchar values will
instead continue running wildly forward. This could mean that a function that's
supposed to return something may actually return nothing, and the caller will
get a garbage value instead (from whatever detritus is left in the return
register when it was last modified).

These problems are already showing up, even in non-release mode. I'm raising
the severity of this bug.

--

Re: extern(C++, ns)

[Walter Bright via Digitalmars-d]

On 1/20/2016 4:17 AM, Manu via Digitalmars-d wrote:

-- name.x.d
module name.x;
-- name.y.d
module name.y;
import name.x;
extern(C++, name) int x;



This won't work any more than:

  import name.y;
  struct name { }

would. You can't have two different definitions for the same identifier in the 
same scope, and that's true for any programming language I've heard of.





extern(C++, delegate) int x;



Yes, we've talked about that. I'm thinking of a solution where it could be 
written like:


extern(C++, delegate_) int x;

and the C++ name mangler strips off any trailing _.

Note that this problem is NOT resolved by your proposed solution, as this 
wouldn't work, either:


   extern(C++) int* delegate();

or any other use of D keywords as C/C++ identifiers.

https://issues.dlang.org/show_bug.cgi?id=15587



You claim this is a problem that must desperately be solved:

int x;
extern(C++, ns) int x;


The solution arrives at basically the same problem:

int ns;
extern(C++, ns) int x;


We've just robbed peter to pay paul?


C++ doesn't allow:

int ns;
namespace ns { ... }

either, so there can never be a need to solve that problem.



scanning reflection
needs to be retrofit with new tricks to recurse into namespaces:

extern(C++, ns) void f();
pragma(msg, __traits(allMembers, mixin(__MODULE__)));


tuple("object", "ns")


... f() is not present.

By extension of this, extern(C++, ns) declarations are incompatible
with every single implementation of scanning reflection I've written
in the past 6 years, and everyone else's too.
All such code needs to be retrofit with new tricks to recurse into ns.


Seems to me that all that is necessary is to replace:

  __traits(allMembers, mixin(__MODULE__))

with:

   getAllMembersIncludingNs(mixin(__MODULE__))

and then write getAllMembersIncludingNS() as a function that recursively adds 
members of namespaces. After all, the ugly __traits() was always meant to be a 
building block to be encapsulated by a function that does what is really wanted. 
I wouldn't call it tricky.

Re: So... add maxCount and maxPos?

[Ivan Kazmenko via Digitalmars-d]

On Wednesday, 20 January 2016 at 17:16:00 UTC, Andrei 
Alexandrescu wrote:
This is one of those cases in which we were pedantically right 
to not add them, but their equivalents look like crap.


https://github.com/D-Programming-Language/phobos/pull/3942


As it seems related, let me share my personal experience with 
minPos.
Most of the time, I want one of the two things related to an 
extremum.


1. The minimum or maximum element itself.  I write it as 
a.minPos.front.  That's almost fine, but maybe there is a more 
expressive way?


2. The index of minimum or maximum element, mostly using plain 
array as a range.  I write "a.length - a.minPos.length", and it 
looks completely unintuitive.  Additionally, when compiling to 64 
bits, I usually still want an int to use with other ints around 
(longs are overkill most of the time), and the cast adds more 
clobber.  Again, is there a better way to express that?


3. Other uses: I've yet to see the need.

In a random collection of my D code, the number of occurrences of 
cases 1:2:3 is 6:4:0.


I've got used to "minPos !(q{a > b})" instead of "maxPos", but a 
maxPos alias would of course make things a bit more clear.  Don't 
know how much of a justification that is.


Ivan Kazmenko.

Re: extern(C++, ns)

[Timon Gehr via Digitalmars-d]

On 01/20/2016 09:56 PM, Walter Bright wrote:

On 1/20/2016 4:17 AM, Manu via Digitalmars-d wrote:

-- name.x.d
module name.x;
-- name.y.d
module name.y;
import name.x;
extern(C++, name) int x;



This won't work  ...


The suggestion was to just not introduce a new symbol/scope for the 
namespace. It would certainly work.

Re: Idea: limited template expansion

[Steven Schveighoffer via Digitalmars-d]

On 1/20/16 4:44 PM, David Nadlinger wrote:

On Wednesday, 20 January 2016 at 21:27:15 UTC, Steven Schveighoffer wrote:

It would be cool if the compiler could "expand" a finitely
instantiable template (one with a finite number of ways it can be
instantiated) based on a runtime value, and do the switch for me.


Can't you just write a wrapper function that takes the template function
as a compile-time argument and generates the switch for you by iterating
over the std.traits.EnumMembers of said compile-time parameter?


I'm sure it can be done using some existing techniques, possibly with 
mixins.


However, one thing I didn't mention is the function called foo would 
likely simply be inline code in the higher level function, if it could be.


Imagine if you such a call returned something, and you simply used it 
throughout the rest of your function. The compiler could rewrite this as 
a template and compile all three versions and branch to the appropriate 
one, but your code would simply read as a straightforward procedural 
function.


In any case, it was an idea that I had, not sure if it makes a lot of 
sense. It would likely be a huge amount of work on the compiler.


-Steve

Re: extern(C++, ns)

[Walter Bright via Digitalmars-d]

On 1/20/2016 4:47 AM, Manu via Digitalmars-d wrote:

As a bonus, the project's C++ namespace 'libname' is already present
in the fully qualified name, it's the top level package! No point
repeating that as 'libname.feature.libname.symbol'.


You can always write a module that all it does is import a bunch of other 
modules, with a bunch of aliases which can be used to make those imports appear 
in another namespace:


   module core.stdcpp.vector
   extern (C++, std) { struct vector { } }

   module core.stdcpp.string
   extern (C++, std) { struct string { } }

   module stl--
   private import core.stdcpp.vector;
   private import core.stdcpp.string;
   ...
   extern (C++, std)
   {
  alias core.stdcpp.vector.std.vector vector;
  alias core.stdcpp.string.std.string string;
  ...
   }

   ---module user-
   import stl;

   std.vector v;
   std.string s;

[Issue 15586] std.utf.toUTF8() segfaults when fed an invalid dchar

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15586

--- Comment #5 from thomas.bock...@gmail.com ---
> Keep in mind, though, that one *could* argue that casting an arbitrary value
> to dchar already constitutes UB

This has already been settled. It's not:
http://forum.dlang.org/post/oionrfexehapzicgp...@forum.dlang.org

> Generally, you probably shouldn't be casting stuff unless you know what
> you're doing and are ready to handle the consequences when things go wrong.

1) No casting is required to trigger this bug. I was just giving you a
simplified test case. Here's a slightly less simple one, without any casts:

import std.stdio;

void main() {
import std.utf : toUTF8;

dchar a = dchar.max;
a += 1;

char[4] buf = void;
auto b = toUTF8(buf, a);

import std.stdio;
writeln(b);
}

2) "If you don't want segfaults, don't cast stuff" is an awful solution to a
hard crash in @safe code. There is no good reason that casts of basic numeric
or character types should cause this kind of failure.

--

Re: extern(C++, ns)

[Martin Drašar via Digitalmars-d]

Dne 20.1.2016 v 23:01 Walter Bright via Digitalmars-d napsal(a):
> I understand his suggestion. I asked Manu to elaborate what the "serious
> problems" are. This code snippet doesn't work as it is not supposed to
> work, but still unknown is what the "serious problem" with it is - and I
> want to ensure that Manu knows this is not a bug in the implementation.

Bugs in implementation are a separate concern. The "serious" problem is
that the decision to have a namespace introduce a new scope needlessly
complicates writing D-like interfaces to C++ code, while catering for
one specific use-case that is considered niche.

Everything in this thread has been repeated at least three times. Yet
you still stand by your design decision and offer more or less
convoluted ways to deal with it.

I guess that at this point it would be great to introduce some hard
data. For example, how often would you encounter the problem with the
same identifiers distinguished by namespaces, if you tried to interface
to some typical C++ libraries. Because, unless you really must have your
interface in one file, this should be fairly rare (at least from my
experience).

Martin

Re: extern(C++, ns)

[Manu via Digitalmars-d]

On 21 January 2016 at 06:56, Walter Bright via Digitalmars-d
 wrote:
> On 1/20/2016 4:17 AM, Manu via Digitalmars-d wrote:
>>
>> -- name.x.d
>> module name.x;
>> -- name.y.d
>> module name.y;
>> import name.x;
>> extern(C++, name) int x;
>> 
>
>
> This won't work any more than:
>
>   import name.y;
>   struct name { }
>
> would. You can't have two different definitions for the same identifier in
> the same scope, and that's true for any programming language I've heard of.

Of course. But I don't know how you keep missing my point; I didn't
declare something called 'name', I declared something called 'x'.
I don't want this namespace called 'name'; I didn't declare it, and it
causes problems, like this.
The obvious response is "well don't declare it then", but that's not
an option we're allowed. I want to opt-out of the namespace. I'd
prefer the default was to opt-in though.

>> 
>> extern(C++, delegate) int x;
>> 
>
>
> Yes, we've talked about that. I'm thinking of a solution where it could be
> written like:
>
> extern(C++, delegate_) int x;
>
> and the C++ name mangler strips off any trailing _.

It's a solution I guess... I wouldn't call it intuitive. Why would
someone reading the code expect that behaviour?
But again, it's completely unnecessary. I don't want a namespace
called 'delegate'.
I don't want to declare any D identifier anywhere called 'delegate', I
just want it to mangle 'x' properly.

You're proposing a work-around to a problem that shouldn't exist in
the first place. The proper solution is to make the problem not exist.

> Note that this problem is NOT resolved by your proposed solution, as this
> wouldn't work, either:
>
>extern(C++) int* delegate();

>> You claim this is a problem that must desperately be solved:
>> 
>> int x;
>> extern(C++, ns) int x;
>> 
>>
>> The solution arrives at basically the same problem:
>> 
>> int ns;
>> extern(C++, ns) int x;
>> 
>>
>> We've just robbed peter to pay paul?
>
>
> C++ doesn't allow:
>
> int ns;
> namespace ns { ... }
>
> either, so there can never be a need to solve that problem.

I'm declaring 'x', not 'ns'. using the namespace to resolve conflict
in the first case just creates a second potential for conflict. It's
kicked the can, and hasn't reliably solved the problem. Name conflict
resolution and name mangling are separate issues, it's no good to
conflate them.
I'd rather resolve the conflict in a normal D way like any normal D
user would. I can best choose how to resolve the conflict with
consideration for the case, and this issue has nothing to do with name
mangling.

>> scanning reflection
>> needs to be retrofit with new tricks to recurse into namespaces:
>> 
>> extern(C++, ns) void f();
>> pragma(msg, __traits(allMembers, mixin(__MODULE__)));
>> 
>>>
>>> tuple("object", "ns")
>>
>>
>> ... f() is not present.
>>
>> By extension of this, extern(C++, ns) declarations are incompatible
>> with every single implementation of scanning reflection I've written
>> in the past 6 years, and everyone else's too.
>> All such code needs to be retrofit with new tricks to recurse into ns.
>
>
> Seems to me that all that is necessary is to replace:
>
>   __traits(allMembers, mixin(__MODULE__))
>
> with:
>
>getAllMembersIncludingNs(mixin(__MODULE__))
>
> and then write getAllMembersIncludingNS() as a function that recursively
> adds members of namespaces. After all, the ugly __traits() was always meant
> to be a building block to be encapsulated by a function that does what is
> really wanted. I wouldn't call it tricky.

">> All such code needs to be retrofit with new tricks to recurse into ns."

I understand I can correct the situation by changing the code, but
there is an awful lot of reflection code that already exists, mostly
in libraries.
Normal programmers don't tend to change library code, they just assume
that it doesn't work.

You guys hate breaking code, I'm surprised you're not more upset by this.
I'm frustrated by the other cases, because you're making me to do work
and waste time here complaining about a problem that simply shouldn't
exist in the first place. This is the one that really upsets me
though.
I don't want the namespace to exist. I just want extern(C++, "ns") to
take a string, not make a scope, every single problem is solved, and
you'll not hear from me for another 6 months.

Re: extern(C++, ns)

[Manu via Digitalmars-d]

On 21 January 2016 at 01:32, Simen Kjaeraas via Digitalmars-d
 wrote:
> On Wednesday, 20 January 2016 at 12:47:44 UTC, Manu wrote:
>
> 2. Multiple modules cannot have the same name in D.



 I'm not sure what situation you're imagining where modules would be
 created with the same names...?

>>>
>>> How do you plan to map C++'s standard lib ? One giant hundred of
>>> thousands of line C++ file ?
>>
>>
>> Surely it would map by file.
>>
>> #include  -> import stl.vector;
>> #include  -> import stl.map;
>> #include  -> import stl.string;
>>
>> Perhaps 'stl' may be something else, 'std' is an unfortunate conflict with
>> phobos, but this is unique to this case.
>
>
> I believe deadalnix here meant something like this:
>
>   import stl.vector;
>   import mylib.vector;
>
>   Vector a; // Ambiguous: could be from mylib or stl
>   stl.Vector b; // Error: no such class stl.Vector
>   stl.vector.Vector c; // Works, but requires extra typing

Okay let me tweak your code:

   import stl.vector;
   import stl.string;   // one more thing; when do you ever only
import a single module?
   import mylib.vector;

   Vector a; // Ambiguous: could be from mylib or stl
   stl.Vector b; // Error: this wouldn't work, becase stl could be
stl.vector.stl or stl.map.stl
   stl.vector.Vector c; // This is what a D programmer expects,
exactly like every other conflict resolution in D ever, but it doesn't
work either

So, it is proposed that people desire to type only stl.Vector to
disambiguate, assuming that 'stl' is a named namespace.
This only works in the rare case that you only import one single
module. This is almost never true!
As soon as you import 2 modules, stl.vector, stl.string for instance,
'stl' is now in conflict, and you require to type:
  stl.vector.stl.Vector c; // Necessary, and even more extra typing!

I am yet to experience a single case of isolated imports... real code
that's not a 3 line test case tends to import more than one thing.
I also object strongly to the rules being different than every other
case of conflict in D that a user has ever experienced.


> Which with working namespaces might allow case b to work.

I hope I've shown how it almost never does, and only makes the situation worse.

Re: Idea: limited template expansion

[David Nadlinger via Digitalmars-d]

On Wednesday, 20 January 2016 at 22:00:45 UTC, Steven 
Schveighoffer wrote:
Imagine if you such a call returned something, and you simply 
used it throughout the rest of your function. The compiler 
could rewrite this as a template and compile all three versions 
and branch to the appropriate one, but your code would simply 
read as a straightforward procedural function.


But if you abstract away the dispatch part into a (meta)template 
function like I suggested, the caller would still be just as 
linear, right?


How would the client code be simpler with a built-in language 
feature?


 — David

Compile-Time RNG

[CTRNG via Digitalmars-d]

I managed to create a compile-time random number generator.

Proof of concept, with some explanatory comments: 
http://dpaste.dzfl.pl/668646ce6d71


Just thought this might be of interest to some of you here.

Re: extern(C++, ns)

[Walter Bright via Digitalmars-d]

On 1/20/2016 3:12 PM, Martin Drašar via Digitalmars-d wrote:

The "serious" problem is
that the decision to have a namespace introduce a new scope needlessly
complicates writing D-like interfaces to C++ code, while catering for
one specific use-case that is considered niche.


Adding a qualifier here and there does not count as serious.

Re: medianOfMedians

[Andrei Alexandrescu via Digitalmars-d]

On 01/20/2016 10:20 AM, Andrei Alexandrescu wrote:
[snip]

And btw I now understand better why medianOfMedians is not so fast in 
practice. In fact my wishy-washy version at 
https://github.com/andralex/phobos/commit/9e004c35b824aac108e0e615183065e73384e9f9 
seems to be practically attractive for choosing a good pivot even though 
it doesn't offer theoretical guarantees. I wonder how some jitter can be 
injected into it so as to improve its worst-case performance.


Andrei

Re: How to know if opSlice is defined for a type (including built-in types)?

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, January 20, 2016 13:06:00 chardetm via Digitalmars-d-learn wrote:
> Anyone who has the same problem: I found
> std.range.primitives.hasSlicing
> (https://dlang.org/phobos/std_range_primitives.html#hasSlicing)
> which does exactly what I want!

Note that because strings are treated as ranges of dchar regardless of what
their actual character type is, arrays of char and wchar (so-called "narrow"
strings) are not consider to have slicing or random access by the traits in
std.range. So, hasSlicing!string is false, though for anything other than an
array of char or wchar, it will do what you're looking for, whereas for
arrays of char or wchar, you really shouldn't be using the slice operator on
them without knowing that they're what you're operating on so that you take
the Unicode issues into account correctly.

- Jonathan M Davis

Re: extern(C++, ns)

[Marc Schütz via Digitalmars-d]

On Wednesday, 20 January 2016 at 05:32:08 UTC, Walter Bright 
wrote:
Actual code examples of the serious problems would be 
appreciated. All the namespace code examples you posted were 
bugs that have since been fixed, or were misunderstandings that 
were explained.


IMO his description was already quite clear, but here you are:

// a.d
module a;

extern(C++, ns) {
void fooa();
void bar();
}

// b.d
module b;

extern(C++, ns) {
void foob();
}
void bar();

// main.d
import a, b;

void main() {
fooa(); // ok
foob(); // ok
bar();  // Error: b.bar at b.d(6) conflicts with a.ns.bar 
at a.d(5)

// let's try to disambiguate: we want ns.bar
ns.bar();   // Error: a.ns at a.d(3) conflicts with b.ns at 
b.d(3)
a.ns.bar(); // works, but requires superfluous `a`, even 
though

// `ns` already makes it unambiguous
}


Of course, it's because of how name lookup works in D, and we 
understand that. But it still diminishes the usability of this 
feature considerably, as the above situation is extremely likely 
to run into if you're porting a sufficiently large C++ library.

Mixin Template Function Attributes

[jmh530 via Digitalmars-d-learn]

I was thinking about using mixin templates to put some 
module-level default information in a single file so that it 
doesn't clutter up other files. It works for imports, but it 
doesn't seem to propagate for function attributes.


module_default.d
---
module module_default;

mixin template module_default()
{
import std.traits : functionAttributes;
import std.stdio : writeln;

@safe:
}

app.d
---
import module_default;

mixin module_default;

int foo(int x)
{
return x;
}

void main() {

writeln(functionAttributes!foo);
}

Compiled with dmd app.d module_default.d on Windows 7 64bit. The 
output is system, when I would expect it to be safe.


I'm not sure if this is how the behavior is supposed to be or if 
it is a bug.

[Issue 15586] std.utf.toUTF8() segfaults when fed an invalid dchar

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15586

--- Comment #4 from hst...@quickfur.ath.cx ---
Keep in mind, though, that one *could* argue that casting an arbitrary value to
dchar already constitutes UB, if dchars are deemed to only contain valid
Unicode codepoints. If you need to work with incoming character data of unknown
validity, you're probably better off working with uint (or uint[], ubyte[],
etc.) instead, and only convert to dchar (string, etc.) after explicit
validation.

Generally, you probably shouldn't be casting stuff unless you know what you're
doing and are ready to handle the consequences when things go wrong.

--

Re: Idea: limited template expansion

[David Nadlinger via Digitalmars-d]

On Wednesday, 20 January 2016 at 21:27:15 UTC, Steven 
Schveighoffer wrote:
It would be cool if the compiler could "expand" a finitely 
instantiable template (one with a finite number of ways it can 
be instantiated) based on a runtime value, and do the switch 
for me.


Can't you just write a wrapper function that takes the template 
function as a compile-time argument and generates the switch for 
you by iterating over the std.traits.EnumMembers of said 
compile-time parameter?


Something like `enumTemplateDispatch!foo(detectBOM(buffer), 
))`.


Depending on what template signatures you want to support, you 
might need to make enumTemplateDispatch explicitly take the enum 
type to use or the position of the respective parameter in the 
template argument list of the target.


 — David

Re: So... add maxCount and maxPos?

[Timon Gehr via Digitalmars-d]

On 01/20/2016 06:16 PM, Andrei Alexandrescu wrote:

This is one of those cases in which we were pedantically right to not
add them, but their equivalents look like crap.

https://github.com/D-Programming-Language/phobos/pull/3942


Andrei


One reason why dual notions usually both receive names is that naming 
one of them but not the other is arbitrary and confusing. (Reversing all 
arrows in the respective category is often just not a very natural 
operation, even if it has a computational interpretation.)


Languages don't just leave out one of && or || either.

Re: Memory Corruption Issue??

[Bottled Gin via Digitalmars-d]

Thanks Daniel

I have added the testcase to a more obscure testcase that I had 
raised on Bugzilla earlier.

https://issues.dlang.org/show_bug.cgi?id=15513

I want to request developers to show some love.

Regards
- Puneet

Re: extern(C++, ns)

[JohnCK via Digitalmars-d]

On Wednesday, 20 January 2016 at 16:38:19 UTC, Marc Schütz wrote:

// a.d
module a;

extern(C++, ns) {
void fooa();
void bar();
}

// b.d
module b;

extern(C++, ns) {
void foob();
}
void bar();

// main.d
import a, b;

void main() {
fooa(); // ok
foob(); // ok
bar();  // Error: b.bar at b.d(6) conflicts with 
a.ns.bar at a.d(5)

// let's try to disambiguate: we want ns.bar
ns.bar();   // Error: a.ns at a.d(3) conflicts with b.ns at 
b.d(3)
a.ns.bar(); // works, but requires superfluous `a`, even 
though

// `ns` already makes it unambiguous
}


I think the first error is correct:

bar();  // Error: b.bar at b.d(6) conflicts with 
a.ns.bar at a.d(5)


So you have two functions bar() one inside 'ns' in module a and 
"outside" 'ns' in module b.


Now, the last 2 errors, Mark Schutz said:

a.ns.bar(); // works, but requires superfluous `a`, even 
though

// `ns` already makes it unambiguous


Question: What happens if you do this: using "ns1" in "module a" 
and "ns2" in "module b" and do:


ns1.bar();

?

Because you can't have more than one namespaces with the same 
name in C++, right?


JohnCK.

Re: Functions that return type

[BLM768 via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 10:04:03 UTC, burjui wrote:
That's alright. Parsing and AST construction are trivial with 
S-expressions (Lisp-like syntax), so if you use them for the 
early stages of development, you can focus on the type system. 
When you're done with types, you can switch to making a better 
grammar for your language.


True. I'd been playing with the idea of having multiple syntactic 
"front-ends" anyway (mainly for the purpose of making DSLs), so 
it wouldn't be too much of a stretch to use an S-expression 
syntax. One problem, though, is that I'd either have to extend 
that syntax to support some of the constructs I want (i.e array 
literals) or create a bunch of variadic constructor functions 
(which could be evaluated at compile time). Of course, 
S-expression syntax is kind of designed to be extensible...


That's all off-topic, though. ;)

Re: Distribution of D apps

[Adam D. Ruppe via Digitalmars-d-learn]

By default, a binary compiled with D will have the standard 
library statically linked in, so all you need to distribute are 
other shared libs you choose to use (which might include curl btw 
if you use the std.net.curl functions).


But many .exes from D can be distributed alone and expected to 
work.

forum.dlang.org is now available via HTTPS

[Vladimir Panteleev via Digitalmars-d]

It took a while but I finally got around to adapting a Let's 
Encrypt ACME client to my hosting system with automatic renewals 
etc. Enjoy!


https://forum.dlang.org/

Adam, your turn!

Re: opIndex, opSlice, length for joiner?

[Jack Stouffer via Digitalmars-d]

On Wednesday, 20 January 2016 at 17:36:29 UTC, Maverick Chardet 
wrote:
The most important issue that comes to my mind is that the 
operations would not take constant time... A trivial 
implementation would be in O(k) where k is the number of joined 
ranges, and with some precomputation in O(k) time and space we 
can make length O(1) and opIndex and opSlice O(log k)... Would 
that be a problem?


I definitely think you should open a PR with your ideas 
regardless of what people say in this thread. Secondly, giving 
the user more options than he/she had before can't really be a 
bad thing, even if the options aren't perfect. That is, if you 
clearly document the trade-offs in the documentation.


But I am saying this before I see the code, so I can't really say 
one way or the other.