Re: Store any callable in an array

2018-05-06 Thread wjoe via Digitalmars-d-learn

Thanks for replying.

On Friday, 4 May 2018 at 19:12:16 UTC, ag0aep6g wrote:

On 05/04/2018 06:33 PM, Neia Neutuladh wrote:

auto asDelegate(TFunc)(TFunc func) @trusted
     import std.functional : toDelegate;
     return toDelegate(func);

The "@trusted" means that you promise this thing is safe, even 
if the compiler can't be certain.

If toDelegate isn't (always) @safe, how can you be sure that 
your wrapper is? Also, TFunc may have an unsafe destructor.

That's not good use of `@trusted`.

Could you elaborate on the unsafe destructor please? Are there 
any other gotchas ?

Re: Store any callable in an array

2018-05-06 Thread wjoe via Digitalmars-d-learn

Thanks for replying.

On Saturday, 5 May 2018 at 00:30:35 UTC, Neia Neutuladh wrote:

On Friday, 4 May 2018 at 19:12:16 UTC, ag0aep6g wrote:
[...] If it's a user-defined type with opCall, that's something 
to pay attention to, but it's beyond the scope of the original 

Actually it's not. Callable structs/classes are use cases I'm 
asking about as well.

Re: Purity of delegate-style toString

2018-05-06 Thread Q. Schroll via Digitalmars-d-learn

On Tuesday, 1 May 2018 at 12:03:15 UTC, ag0aep6g wrote:

On 05/01/2018 01:44 PM, Per Nordlöw wrote:
In which cases (if any) is it possible to make a 
delegate-style implementation of toString such as

     void toString(scope void delegate(const(char)[]) sink) 
const @trusted pure

     // sink("...");
     // sink.formattedWrite!"..."(...);


You have to mark `sink` as pure, too:

void toString(scope void delegate (const(char)[]) pure sink)
const @trusted pure

Then the toString method itself works, but it may not be 
callable by other code that wants to use an impure sink.

For example, `format` works, but `writeln` doesn't:

struct S
void toString(scope void delegate(const(char)[]) pure sink)
const @trusted pure
import std.format: formattedWrite;
sink.formattedWrite!"%s"(" ...");
void main()
import std.format: format;
import std.stdio: writeln;
writeln(format("%s", S())); /* Ok. Prints "... ...". */
writeln(S()); /* Nope. writeln would like to use an impure 
sink. */


By the way, you shouldn't mark toString as @trusted when `sink` 
is @system.

I had similar issue for opApply.

The generalized problem is, the attributes (pure, nothrow, @safe, 
@nogc) are too strong on functionals (i.e. functions taking 
function/delegate arguments). We could (and IMO should) weaken 
the attributes to mean: the same as always, *assuming all 
function/delegate arguments have it*.

Concrete example, say your `toString(scope void 
delegate(const(char)[]))` is conceptually pure, i.e. if `sink` is 
a pure function (by static typing), `toString(sink)` acts pure, 
and for impure `sink`, `toString(sink)` possibly impure. So 
purity of the functional `toString` depends on the purity of its 
arguments; that is very natural as most functionals call their 

The current state makes attributes virtually useless for 
functionals. Often, toString can be templetized without drawback 
(except virtual functions), but opApply cannot. opApply must not 
be a template to enable type deduction for the variable.[1]

Making attributes act structurally has almost no consequences in 
terms of breakage; just more functions can be 
pure/nothrow/@nogc/@safe. It would make functionals 
that do not call their argument. The question is, in which 
contexts are they used and is it an issue -- is it a greater 
issue than this.

Complete example what the change would do:
Say you have

  void toString(scope void delegate(const(char)[]) sink) pure { 
sink("Example"); }

toString is a pure functional, so calling it is pure iff the 
argument itself is. The compiler statically knows if the argument 
is pure and can infer the purity of the expression.

(We could define very general special cases where type deduction 
can be archived, e.g. opApply(DG : int delegate(Args))(DG).)

Overload Resulution Template with 2 Functions vs. 2 Templates difference

2018-05-06 Thread Q. Schroll via Digitalmars-d-learn

Why is there a difference between

struct S
  template func(T)
enum impl = "whatever string";
auto func(T arg)   { mixin(impl); } // eponymous template
auto func(T arg) const { mixin(impl); } // eponymous template


struct R
  private enum impl = "whatever string";
  auto func(T)(T arg)   { mixin(impl); }
  auto func(T)(T arg) const { mixin(impl); }

And what is the difference exactly? I know that
  auto func(T)(T arg) { mixin(impl); }
is strictly equivalent to
  template func(T) { auto func(T)(T arg) { mixin(impl); } }
so the difference is just 2 templates 1 function each vs. 1 
template 2 functions.

I don't have a simple example; here is no difference observable. 
The issue is with std.typecons.Tuple.opCmp; there are two 
templates and I tried making it one, as the implementation is 
identical. Unfortunately, one cannot use `inout` for more or less 
obcious reasons.
An attempt to put them into one template (as for struct S) does 
not work either, but I don't understand why. Solution like struct 
R works.

Is there a complete reference for how overload resolution works 
in D, including implicit template instantiation?

Re: C++ / const class pointer signature / unable to find correct D syntax

2018-05-06 Thread Rubn via Digitalmars-d-learn

On Friday, 4 May 2018 at 07:57:26 UTC, Uknown wrote:

On Friday, 4 May 2018 at 07:49:02 UTC, Robert M. Münch wrote:
I have a static C++ and can't make it to get a correct binding 
for one function:

DMD: public: unsigned int __cdecl b2d::Context2D::_begin(class 
b2d::Image & __ptr64,class b2d::Context2D::InitParams const * 
__ptr64 const) __ptr64
LIB: public: unsigned int __cdecl b2d::Context2D::_begin(class 
b2d::Image & __ptr64,class b2d::Context2D::InitParams const * 
__ptr64) __ptr64

So I somehow get some more const from D. This is the code I 

   final uint _begin(ref Image image, const(InitParams) 

Which creates a const pointer to a const class signature. But 
it should only be a const pointer. Any idea how to solve this?

The problem is that const in D is transitive. That means T * 
const from C++ is not expressible in D. Any reference through a 
const becomes const. To use it, IMO your best bet is to make a 
wrapper function on the C++ side like this:

unsigned int __cdecl b2d::Context2D::_begin(class b2d::Image & 
im,class b2d::Context2D::InitParams const * const InitParams)

return //the call to the original c++ function

Alternatively you can use dpp, or dstep or some similar tool to 
try and let the tool create bindings. As a last ditch, you can 
force the mangle to match by using pragma(mangle, ...) like 

pragma(mangle, _ZactualMangleFromC++Compiler)
final uint _begin(ref Image image, const(InitParams) 

Using pragma(mangle) isn't really a solution though, unless you 
only plan on using one platform/compiler. C++ doesn't have a 
single standard name mangling. You would need to get the name 
mangling for every compiler you plan to use then use a version 
define fore each. Which isn't really practical for how many 
bindings you would need to do that for.

The easiest solution is to just write C bindings for the C++ 
library then use those instead from D.

Re: could someone test support for Asian languages in nanogui port?

2018-05-06 Thread drug via Digitalmars-d-learn

On 06.05.2018 06:10, Binghoo Dang wrote:


I'm a Chinese, and I just have done the test. I also copied some 
Japanese text from Dlang twitter channel and added some Chinese wide 
punctuation Char.

And It's all seems displayed correctly.

The resulting screenshot is here:

The only problem is that the font style simply looks strange. You can 
see the 'normal' text display in Win10 by default like this:

Can it fixed by other font or there are some other problems?

And the font problem is probably related to SDL or GL, for all UI based 
on GL or SDL, they all have the same problem. Dlangui also has the same 
situation, that's why I just did not use Dlangui for a production project.

Could you describe the problem in more details?

But, Anyway, the text is displayed correctly.

Great work for doing this! Dlang needs a great GUI framework.

Thank you for your time!