Re: Deduce type of struct in function arguments

2018-08-21 Thread Jonathan M Davis via Digitalmars-d-learn
On Tuesday, August 21, 2018 6:56:06 PM MDT Mike Parker via Digitalmars-d-
learn wrote:
> On Tuesday, 21 August 2018 at 14:56:21 UTC, Seb wrote:
> > I'm aware, but we don't have any other process for people to
> > show their support for a DIP, do we?
> >
> >
> > And for DMD/Druntime/Phobos etc. having a bunch of +1 helps a
> > PR to move faster as we as reviewers can thus realize that this
> > is sth. that's very important to the community.
>
> Sure, I know you know. I didn't want anyone reading what you
> wrote to get the impression that DIP reviews are an actual vote
> where the +1s are tallied up.

It would probably be better to tell people to show their appreciation or
support for the DIP by adding +1 to it than it would be to say anything
about voting, since no voting is involved, and this is not a democratic
process in any way shape or form. LOL. It's much more like a petition to the
king. :)

- Jonathan M Davis





Re: Deduce type of struct in function arguments

2018-08-21 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 21 August 2018 at 14:56:21 UTC, Seb wrote:


I'm aware, but we don't have any other process for people to 
show their support for a DIP, do we?



And for DMD/Druntime/Phobos etc. having a bunch of +1 helps a 
PR to move faster as we as reviewers can thus realize that this 
is sth. that's very important to the community.


Sure, I know you know. I didn't want anyone reading what you 
wrote to get the impression that DIP reviews are an actual vote 
where the +1s are tallied up.


Re: Coreect way to create delegate for struct method.

2018-08-21 Thread Alex via Digitalmars-d-learn

On Tuesday, 21 August 2018 at 21:29:38 UTC, Andrey wrote:

Hello,
This is a code:

import std.stdio;

struct Test
{
   static Test opCall()
   {
   Test test;
   test.handler = 

   return test;
   }

   void one() const { writeln("In handler: Address = ", , 
"; Text = ", text); }


   void execute()
   {
   text = "Inited!";
   writeln("Before: Address = ", , "; Text = ", text);
   handler();
   }

   void delegate() const handler = void;
   string text = "NoValue";
}

struct Qwerty
{
   void prepare()
   {
   _test = Test();
   }

   void execute()
   {
   _test.execute();
   }

private:
   Test _test  = void;
}

void main()
{
   Qwerty qwerty;
   qwerty.prepare();
   qwerty.execute();
}


Here I try to make a delegate for struct "Test" and method 
"one()".

When I launch it then I get this output:

Before: Address = 7FFC096A2C20; Text = Inited!
In handler: Address = 7FFC096A2BE8; Text = NoValue


It means that my delegate captures one object of Test, but in 
place of call uses another...
I want just to save my method into variable and after that use 
it on some arbitrary object of type "Test". How to do it in D?


In C++ it is very easy:

test.handler = ::one;

and call:

(this->*handler)();

or

(someTestObjPtr->*handler)();
I know axactly that in the first variant a context will be 
"this", and in the second - "someTestObjPtr".


Maybe, like this:

´´´
import std.stdio;

struct Test
{
static auto opCall()
{
auto test = new Test();
test.handler = 
return test;
}

void one() const { writeln("In handler: Address = ", , 
"; Text = ", text); }


void execute()
{
text = "Inited!";
writeln("Before: Address = ", , "; Text = ", text);
handler();
}

void delegate() const handler = void;
string text = "NoValue";
}

struct Qwerty
{
void prepare()
{
_test = Test();
}

void execute()
{
_test.execute();
}

private:
Test* _test  = void;
}

void main()
{
Qwerty qwerty;
qwerty.prepare();
qwerty.execute();
}
´´´


Re: Are properties mature enough?

2018-08-21 Thread Jonathan M Davis via Digitalmars-d-learn
On Tuesday, August 21, 2018 1:46:31 PM MDT Jim Balter via Digitalmars-d-
learn wrote:
> That's a lot of detail. The bottom line is that the warning in
> the spec is completely wrong and should be removed -- using
> property functions is not discouraged, nor is @property.
> @property should be used, both as documentation and because it
> makes typeof work correctly. Maybe it will do even more later.

Whether it makes typeof work correctly is a matter of debate. It makes it
act more like a varable, which is in line with the property function acting
like a variable. However, it isn't actually a variable, and aside from
calling the function without parens or being able to assign to it, it really
doesn't act like a variable. So, having typeof claim that it is actually
tends to cause problems when doing metaprogramming. Also, because @property
isn't required to get the property syntax, what typeof says really doesn't
have much to do with what's syntactically valid. What usually makes more
sense is to check the type of expressions using the symbol rather than
directly checking the type of the symbol. So, while @property serves as a
good way to indicate the intent of the API author, all it really does beyond
that is cause problems with metaprogramming. So, while I definitely use it,
I'd honestly argue that the fact that typeof lies about what the actual type
is when @property is used is a serious problem.

- Jonathan M Davis





Re: Auto keyword and when to use it

2018-08-21 Thread QueenSvetlana via Digitalmars-d-learn

On Tuesday, 21 August 2018 at 18:44:15 UTC, Jim Balter wrote:
Python is not statically typed; D is. Why are you talking about 
Python? You asked whether D's auto is like C#'s var ... it is, 
but it doesn't have C#'s pointless restriction of not being 
allowed for non-local declarations.


I think you misunderstood my point. Let me elaborate. In Python a 
type could change at anytime, for example:


number = 1

In Python the variable number will be treated as an int, but at 
any point in my code, that could change, in Python this is legal:


number = "one"

The code will compile and run. Now Python introduced type hints 
to tell the reader how to treat the variable.


The problem with the code is, when you have a class, take my 
Person example, a person will obviously have a first and last 
name, which should be strings, now without validation I can pass 
ints to those variables, which is undesirable. I would need a 
private function to check the types passed and reject it if they 
aren't strings, in addition to if the string is blank or contains 
foreign characters.


I had a misunderstanding about the keyword auto because I 
wrongfully believed that it made the code like Python, and for 
that I apologize. I thought you were allowed to make class 
variables auto, so for example:


class Person{

auto firstName
auto lastName
}

If this was allowed, when I create my person object, I can pass 
ints to firstName and lastName, which is obviously undesirable. I 
would need to check what value types were passed and reject them 
if they aren't strings.


As pointed out in the answers above, this isn't legal, which 
means, there is no need to check anything, it won't compile.


Re: Generically call a function on Variant's payload?

2018-08-21 Thread Nick Sabalausky (Abscissa) via Digitalmars-d-learn

On 08/21/2018 03:27 PM, Steven Schveighoffer wrote:


If you examine how the code for variant works, it's quite clever. It 
establishes a "handler" that is generated with full compile-time type 
info available when the value is *assigned*, but then cast to a function 
taking a void pointer and an operation. This way, the user of the 
variant doesn't have to know what is inside, just the handler does. The 
code that sets the payload is the one that establishes how to use it.


The same type of pattern could be used to, for instance, provide all the 
functions that a range uses.


But it's not something that can be tacked on to Variant. You'd have to 
write your own type, because you'd have to handle the different 
functions that you know are common between the types in question (e.g. 
the operations supported on a variant are here: 
https://github.com/dlang/phobos/blob/master/std/variant.d#L163)


Oooh, that's really cool! I might try my hand at something like that.

I bet it actually could be generalized to a certain extent. Variant 
would just have to be templated on the expected interface. Then it could 
compile-time loop over the list of functions expected, and introspect 
each of them enough to build the handler and the forwarders. Doesn't 
exactly sound fun to implement, but I'd bet it could be done.


Coreect way to create delegate for struct method.

2018-08-21 Thread Andrey via Digitalmars-d-learn

Hello,
This is a code:

import std.stdio;

struct Test
{
   static Test opCall()
   {
   Test test;
   test.handler = 

   return test;
   }

   void one() const { writeln("In handler: Address = ", , 
"; Text = ", text); }


   void execute()
   {
   text = "Inited!";
   writeln("Before: Address = ", , "; Text = ", text);
   handler();
   }

   void delegate() const handler = void;
   string text = "NoValue";
}

struct Qwerty
{
   void prepare()
   {
   _test = Test();
   }

   void execute()
   {
   _test.execute();
   }

private:
   Test _test  = void;
}

void main()
{
   Qwerty qwerty;
   qwerty.prepare();
   qwerty.execute();
}


Here I try to make a delegate for struct "Test" and method 
"one()".

When I launch it then I get this output:

Before: Address = 7FFC096A2C20; Text = Inited!
In handler: Address = 7FFC096A2BE8; Text = NoValue


It means that my delegate captures one object of Test, but in 
place of call uses another...
I want just to save my method into variable and after that use it 
on some arbitrary object of type "Test". How to do it in D?


In C++ it is very easy:

test.handler = ::one;

and call:

(this->*handler)();

or

(someTestObjPtr->*handler)();
I know axactly that in the first variant a context will be 
"this", and in the second - "someTestObjPtr".


Re: Are properties mature enough?

2018-08-21 Thread Jim Balter via Digitalmars-d-learn

On Monday, 20 August 2018 at 00:49:02 UTC, Jonathan M Davis wrote:
On Sunday, August 19, 2018 12:32:17 PM MDT QueenSvetlana via 
Digitalmars-d- learn wrote:

In the D Style Guide, it says:

Properties
https://dlang.org/dstyle.html#properties

Functions should be property functions whenever appropriate. 
In particular, getters and setters should generally be avoided 
in favor of property functions. And in general, whereas 
functions should be verbs, properties should be nouns, just 
like if they were member variables. Getter properties should 
not alter state.


In the Properties function section, it says:

https://dlang.org/spec/function.html#property-functions

WARNING: The definition and usefulness of property functions 
is being reviewed, and the implementation is currently 
incomplete. Using property functions is not recommended until 
the definition is more certain and implementation more mature.


So which is it?


Feel free to use @property or not, but the main point in the 
style guide is about naming functions, not about @property. The 
idea is that functions that wrap or emulate variables should 
act like variables themselves. So, they should be named as if 
they were variables and syntactically used as if they were 
variables rather than prepending their names with get or set 
and calling them as functions. e.g.


struct S
{
int prop() { return _prop; }
int prop(int val) { return _prop = prop; }

private int _prop;
}

with

auto r = s.prop;
s.prop = 42;

instead of

struct S
{
int getProp() { return _prop; }
int setProp(int val) { return _prop = prop; }

private int _prop;
}


auto r = s.getProp();
s.setProp(42).

Marking property functions with @property is an extremely 
popular thing to do, but all it really does at this point is 
document that the programmer intends for it to be used as a 
property rather than enforce anything.


IMHO, the spec words that bit too strongly, and it should be 
fixed. That bit got added recently, because one of the devs 
didn't understand the @property situation, and when he found 
out what it was, he felt that the spec needed to be clarified 
about it so that folks didn't think that it was what the spec 
was claiming, but clearly, he's just confused matters in a 
different way.


Here's the deal. Using the property syntax with functions 
really has nothing to do with @property. It's just based on the 
signature that a function has. If it's a free function, and it 
has a return value but no arguments, without using UFCS, it can 
be used as a getter


int prop();

auto r = prop;

If it has a single argument, or it returns by ref, then it can 
be used as a setter.


ref int prop();
int prop(int);
void prop(int);

all work with

prop = 42;

though the first two can also be used in chained assignment 
operations, since they also return a value, whereas the third 
can't be. e.g.


auto foo = prop = 19;

works with the first two but not the third.

All of the same signatures as member functions also work in the 
same way except that you then get


auto r = obj.prop;

for the getter and

obj.prop = 42;

for the setter. And if they're free functions, and you want to 
use them with UFCS, then they each need one more parameter. e.g.


int prop(MyObj);

auto r = obj.prop;

for the getter and

ref int prop(MyObj);
int prop(MyObj, int);
void prop(MyObj, int);

obj.prop = 42;

for the setter. All of this works regardless of anything to do 
with @property and has had since well before @property existed 
(well, aside from using it with UFCS, since UFCS came later). 
However, a number of folks thought that it was too messy to 
allow any old function with the right set of parameters to be 
used with the property syntax rather than requiring that it be 
part of the API that it be a property function. Probably the 
most egregious case is that something like


writeln = 42;

works just fine, and writeln is clearly a function, not a 
function emulating a variable (which is what a property 
function is supposed to be). So, to improve the situation, 
@property was proposed.


The idea was that functions marked with @property and the 
correct number of parameters would work as property functions 
and that they would _have_ to use the property syntax when 
being used, whereas functions that weren't marked with 
@property were not allowed to use the property syntax. The 
ad-hoc nature of the whole thing then goes away, and stuff like


writeln = 42;

is then illegal. It also fixes the problem where the function 
returns a callable (e.g. a delegate or a functor). If you have 
the function foo, and it returns a callable, as long as it's 
legal to call the function with the property syntax - foo - or 
without - foo() - there's no way to distinguish when the 
callable that's returned by the function should be called. If 
foo is treated as a property, then foo() would call the 
callable that 

Re: Auto keyword and when to use it

2018-08-21 Thread Jonathan M Davis via Digitalmars-d-learn
On Tuesday, August 21, 2018 12:22:42 PM MDT QueenSvetlana via Digitalmars-d-
learn wrote:
> On Monday, 20 August 2018 at 17:55:11 UTC, JN wrote:
> > class Foo
> > {
> >
> > auto bar;
> >
> > }
> >
> > because now the compiler doesn't know what type 'bar' is
> > supposed to be.
>
> Just to clarify, even if I set bar in the constructor, I can't
> declare it with auto first, correct? I would have to declare a
> specific type?

Yes. As Mike's excellent response explained, auto is simply used to indicate
that you're not providing the explicit type and that it should be inferred
from the direct initialization of the variable. Whenever an explicit type is
not provided for a variable when declaring it, you _must_ use direct
initialization so that the type can be inferred. You can't do something like
have the type of a member variable inferred from what the constructor is
doing. And code like

auto foo;

is never legal.

- Jonathan M Davis





Re: Auto keyword and when to use it

2018-08-21 Thread Jonathan M Davis via Digitalmars-d-learn
On Tuesday, August 21, 2018 9:04:31 AM MDT Steven Schveighoffer via 
Digitalmars-d-learn wrote:
> On 8/20/18 9:15 PM, Mike Parker wrote:
> > I tend to use type inference liberally, almost always with
> > const/immutbale locals, though I tend to use auto only when the type
> > name is longer than four characters. For me, it's a nice way to save
> > keystrokes. Some take a dim view of that approach and prefer to use it
> > only when they actually require type inference. I mostly program alone,
> > though, and I have a number of habits others may label 'bad', so I'm
> > happy with my approach.
>
> I'm more extreme in this camp -- I use auto everywhere. Why? because at
> some point, I may change some type somewhere (oops, I should have wrote
> size_t instead of uint), and then I would have to go through and change
> all the places I put the concrete type if I hadn't used auto.
>
> While using functions, I also can use auto and not have to worry about
> the type. I know kind of what it is (integer type, string type, range
> type, etc), and not care what the exact type is.

I'd argue that it's generally better to use explicit types where possible in
function signatures so that the documentation is clearer, but overall, I
agree with you, and if I can use type inference, I almost always do.
However, it does seem like the sort of thing that many newcomers to D balk
at initially, whereas most of us who have been using it for a while have no
problem with it and prefer it.

- Jonathan M Davis





Re: Generically call a function on Variant's payload?

2018-08-21 Thread Steven Schveighoffer via Digitalmars-d-learn

On 8/21/18 3:11 PM, Nick Sabalausky (Abscissa) wrote:

On 08/21/2018 03:03 AM, Nicholas Wilson wrote:
On Monday, 20 August 2018 at 00:27:04 UTC, Nick Sabalausky (Abscissa) 
wrote:
Suppose I've wrapped a Variant in a struct/class which ensures the 
Variant *only* ever contains types which satisfy a particular 
constraint (for example: isInputRange, or hasLength, etc...).


Is there a way to call a function (ex: popFront) on the Variant, 
*without* knowing ahead of time all the possible static types it 
might might contain?


I assume you mean at compile time AoT of development of your library?

Yes, don't use Variant; use https://github.com/s-ludwig/taggedalgebraic



TaggedAlgebraic requires a finite list of every type it can contain. 
That's the deal-breaker for what I had in mind. I need something less 
like Algebraic and more like Variant, which *doesn't* require a finite, 
canonical list of every type it can contain.


The more I think about it though, the more I'm not so sure that the 
extensibility is important enough to warrant all of this, or...more 
importantly...that all of this is even necessary anyway for users to 
accomplish the use-cases I had in mind. I think I may go with an 
entirely different approach.


If you examine how the code for variant works, it's quite clever. It 
establishes a "handler" that is generated with full compile-time type 
info available when the value is *assigned*, but then cast to a function 
taking a void pointer and an operation. This way, the user of the 
variant doesn't have to know what is inside, just the handler does. The 
code that sets the payload is the one that establishes how to use it.


The same type of pattern could be used to, for instance, provide all the 
functions that a range uses.


But it's not something that can be tacked on to Variant. You'd have to 
write your own type, because you'd have to handle the different 
functions that you know are common between the types in question (e.g. 
the operations supported on a variant are here: 
https://github.com/dlang/phobos/blob/master/std/variant.d#L163)


-Steve


Re: Generically call a function on Variant's payload?

2018-08-21 Thread Nick Sabalausky (Abscissa) via Digitalmars-d-learn

On 08/21/2018 03:03 AM, Nicholas Wilson wrote:
On Monday, 20 August 2018 at 00:27:04 UTC, Nick Sabalausky (Abscissa) 
wrote:
Suppose I've wrapped a Variant in a struct/class which ensures the 
Variant *only* ever contains types which satisfy a particular 
constraint (for example: isInputRange, or hasLength, etc...).


Is there a way to call a function (ex: popFront) on the Variant, 
*without* knowing ahead of time all the possible static types it might 
might contain?


I assume you mean at compile time AoT of development of your library?

Yes, don't use Variant; use https://github.com/s-ludwig/taggedalgebraic



TaggedAlgebraic requires a finite list of every type it can contain. 
That's the deal-breaker for what I had in mind. I need something less 
like Algebraic and more like Variant, which *doesn't* require a finite, 
canonical list of every type it can contain.


The more I think about it though, the more I'm not so sure that the 
extensibility is important enough to warrant all of this, or...more 
importantly...that all of this is even necessary anyway for users to 
accomplish the use-cases I had in mind. I think I may go with an 
entirely different approach.


Re: ushort + ushort = int?

2018-08-21 Thread Jim Balter via Digitalmars-d-learn

On Monday, 20 August 2018 at 08:34:56 UTC, Andrey wrote:

Hello,
Here is a code that you can execute using online compiler 
https://run.dlang.io/:



import std.stdio;
void main()
{
   ushort first = 5;
   ushort second = 1000;

   ushort result = first + second;

   writeln(result);
}


I hae this error:
onlineapp.d(7): Error: cannot implicitly convert expression 
cast(int)first + cast(int)second of type int to ushort


Why they are "int" when I declared them as "ushort"???
ushort + ushort = ushort, not int.

In C++ there aren't any such issues...


Only if you make the mistake of compiling without warnings. 
Otherwise, the C++ compiler will warn that you're converting an 
int to a ushort.


Re: Auto keyword and when to use it

2018-08-21 Thread Jim Balter via Digitalmars-d-learn

On Tuesday, 21 August 2018 at 18:18:25 UTC, QueenSvetlana wrote:

On Tuesday, 21 August 2018 at 16:15:32 UTC, XavierAP wrote:

Only if someone
likes "Type x = new Type()" instead of "auto x = new Type()" I 
would say they're clearly wrong.


As you stated it's up to the programmer to decided. I'm in 
favor of Type x = new Type()


There is nothing to recommend such redundancy; don't do it.

because when it comes to constructing a class it usually means 
more code to verify the types


Type inference doesn't require more code.


for example:


Your example has no bearing on any of the above ... it's not an 
example of it.




class Person {
  auto firstName;
  auto lastName;

  // constuctor to set first and last names

}


That code is meaningless and isn't legal. You need to either 
provide explicit types, or they need to be inferable from the 
type of the initializer.


The compiler doesn't know know what firstName or lastName is 
supposed to be and a programmer might make the obvious 
assumption and use them as strings.


The programmer can't make any assumption because the code is not 
remotely legal.


Doing this also means you have reject any type that isn't a 
string which means a private function to check the type that 
was pass to the constructor before initializing it. Where as if 
you declared it as a string to start of with, all you have to 
ensure is that it's not blank or contain illegal characters.


This is all incoherent. D is a statically typed language.

As the answer stated above doing what I showed in my example 
isn't allowed and this is where Python gets frustrating, 
because at any point the types could change. They introduced 
type hints, but it's not enforced, it just makes it more 
readable, you still have to write code to ensure the proper 
types were passed.


Python is not statically typed; D is. Why are you talking about 
Python? You asked whether D's auto is like C#'s var ... it is, 
but it doesn't have C#'s pointless restriction of not being 
allowed for non-local declarations.




Re: Auto keyword and when to use it

2018-08-21 Thread QueenSvetlana via Digitalmars-d-learn

On Monday, 20 August 2018 at 17:55:11 UTC, JN wrote:

class Foo
{
auto bar;
}

because now the compiler doesn't know what type 'bar' is 
supposed to be.


Just to clarify, even if I set bar in the constructor, I can't 
declare it with auto first, correct? I would have to declare a 
specific type?




Re: Auto keyword and when to use it

2018-08-21 Thread QueenSvetlana via Digitalmars-d-learn

On Tuesday, 21 August 2018 at 16:15:32 UTC, XavierAP wrote:

Only if someone
likes "Type x = new Type()" instead of "auto x = new Type()" I 
would say they're clearly wrong.


As you stated it's up to the programmer to decided. I'm in favor 
of Type x = new Type() because when it comes to constructing a 
class it usually means more code to verify the types, for example:



class Person {
  auto firstName;
  auto lastName;

  // constuctor to set first and last names

}

The compiler doesn't know know what firstName or lastName is 
supposed to be and a programmer might make the obvious assumption 
and use them as strings.


Doing this also means you have reject any type that isn't a 
string which means a private function to check the type that was 
pass to the constructor before initializing it. Where as if you 
declared it as a string to start of with, all you have to ensure 
is that it's not blank or contain illegal characters.


As the answer stated above doing what I showed in my example 
isn't allowed and this is where Python gets frustrating, because 
at any point the types could change. They introduced type hints, 
but it's not enforced, it just makes it more readable, you still 
have to write code to ensure the proper types were passed.


Re: Auto keyword and when to use it

2018-08-21 Thread XavierAP via Digitalmars-d-learn

On Monday, 20 August 2018 at 17:52:17 UTC, QueenSvetlana wrote:


So I can't declare class level variables with auto, correct? 
only local method variables?


One difference between D's auto and C#'s var or C++'s auto is 
that the latter languages allow automatically typed declarations 
only for local (method/function-scope) variables, and forbid them 
for class or struct member variables (aka fields); whereas D 
allows auto anywhere (even function/method return type! -- which 
C# and C++ allow as well but only case of anonymous 
methods/lambdas).


I'm in favor of the AAA ("Auto" Almost Always) paradigm, but as 
long as the type if obvious to a human reader. I don't favor them 
for numeric types for this reason (non obvious bitsize, 
signedness...) It's up to each programmer. Only if someone likes 
"Type x = new Type()" instead of "auto x = new Type()" I would 
say they're clearly wrong.


Re: Dub and it's build directory

2018-08-21 Thread Seb via Digitalmars-d-learn
On Tuesday, 21 August 2018 at 12:31:20 UTC, Petar Kirov 
[ZombineDev] wrote:
What Dub does is what it calls "platform probing" [3]. It 
creates a temporary .d file containing various `pragma (msg, 
..)` statements that output information to stderr during 
compilation. Of course the question is then: which compiler is 
used to compile the platform probe file? AFAICS, it uses either 
the one requested for on the command-line (via --compiler=... ) 
or via an internal heuristic which is a bit involved [4].


FYI: the plan is to use the new JSON interface (e.g. `dmd 
-Xi=compilerInfo -Xf=-) soon.


See also: https://github.com/dlang/dub/pull/1316


Re: Auto keyword and when to use it

2018-08-21 Thread Steven Schveighoffer via Digitalmars-d-learn

On 8/20/18 9:15 PM, Mike Parker wrote:
I tend to use type inference liberally, almost always with 
const/immutbale locals, though I tend to use auto only when the type 
name is longer than four characters. For me, it's a nice way to save 
keystrokes. Some take a dim view of that approach and prefer to use it 
only when they actually require type inference. I mostly program alone, 
though, and I have a number of habits others may label 'bad', so I'm 
happy with my approach.


I'm more extreme in this camp -- I use auto everywhere. Why? because at 
some point, I may change some type somewhere (oops, I should have wrote 
size_t instead of uint), and then I would have to go through and change 
all the places I put the concrete type if I hadn't used auto.


While using functions, I also can use auto and not have to worry about 
the type. I know kind of what it is (integer type, string type, range 
type, etc), and not care what the exact type is.


-Steve


Re: Deduce type of struct in function arguments

2018-08-21 Thread Seb via Digitalmars-d-learn

On Tuesday, 21 August 2018 at 08:47:53 UTC, Mike Parker wrote:

On Tuesday, 21 August 2018 at 08:32:17 UTC, Seb wrote:



How and where to vote?


At the pull request via +1 and the upcoming "official" 
discussion of the PR.




Except that there's no voting process for DIPs. The Community 
Review is not intended as a way to vote, simply to provide 
feedback on it with the aim of making it a better proposal. I 
know people tend to throw their +1's in there, but I wouldn't 
expect Walter and Andrei to put any weight on that.


I'm aware, but we don't have any other process for people to show 
their support for a DIP, do we?



And for DMD/Druntime/Phobos etc. having a bunch of +1 helps a PR 
to move faster as we as reviewers can thus realize that this is 
sth. that's very important to the community.


Re: Cast to original type each argument in template pack

2018-08-21 Thread Alex via Digitalmars-d-learn

On Tuesday, 21 August 2018 at 08:08:58 UTC, Andrey wrote:

Hello,
I have a function:

string format(string pattern, T...)(T value)
{
   auto writer = appender!string();
   
writer.formattedWrite!pattern(convertToUnderlyingType(value)); 
//Tuple!T(value).expand.to!(OriginalType!T)


   return writer.data;
}


The "value" in this function can be any type including "enum". 
And if it is a "enum" I want to print it's contents not name.
So what I need - check if current argument in template pack is 
enum then convert it in original type. If current argument 
isn't enum - leave it as is. In my example I showed it with 
imaginary function "convertToUnderlyingType".

How to implement it in D?


Do you mean something like this:

´´´
import std.stdio;
import std.traits;
import std.range;
import std.format;
import std.meta;

enum E
{
A = "a",
B = "b"
}
void main()
{
format!"%s"("kuku").writeln;
format!"%s"(E.A).writeln;
format!"%s %s"("kuku", E.A).writeln;
}

string format(string pattern, T...)(T vals)
{
auto writer = appender!string();

writer.formattedWrite!pattern(convertToUnderlyingType!(vals)); 
//Tuple!T(value).expand.to!(OriginalType!T)


return writer.data;
}

template convertToUnderlyingType(T...)
{
	alias convertToUnderlyingType = 
staticMap!(convertToUnderlyingTypeSingle, T);

}

auto convertToUnderlyingTypeSingle(alias value)()
{
static if(is(typeof(value) == enum))
{
return cast(OriginalType!(typeof(value)))value;
}
else
{
return value;
}
}
´´´


Re: Dub and it's build directory

2018-08-21 Thread Petar via Digitalmars-d-learn

On Monday, 20 August 2018 at 18:59:23 UTC, Russel Winder wrote:

Hi,

[...]


Hi Russel,


So the questions are:

1. How does Dub find the compiler version number, in this case 
2.081, given that neither DMD or LDC seem to have a way of 
delivering only the version number.


The __VERSION__ [1] special token gives you an integer like 2081 
at compile-time. For DMD, LDC and GDC this is the version of the 
DMD frontend they are based on. Obviously, for other compilers 
(not based on the DMD frontend like SDC) there would be no 
equivalent integer, but since there's no other mature alternative 
D implementations this is not a problem in practice. Since the 
__VERSION__ token is replaced with an integer literal at 
compile-time, it can be used for things like conditional 
compilation (e.g. when you want support multiple versions of a 
dmd+druntime+phobos release, for exmaple: [2]).


What Dub does is what it calls "platform probing" [3]. It creates 
a temporary .d file containing various `pragma (msg, ..)` 
statements that output information to stderr during compilation. 
Of course the question is then: which compiler is used to compile 
the platform probe file? AFAICS, it uses either the one requested 
for on the command-line (via --compiler=... ) or via an internal 
heuristic which is a bit involved [4].



2. What is the pseudo-random number, and how is it calculated?


It's an MD5 hash of all the various parameters of a dub build 
(aka the build settings). It's calculated here: [5].


Perhaps some of the information is documented somewhere (if not 
it should be), but I found it easier to search through the code.


Petar

[1]: https://dlang.org/spec/lex.html#specialtokens
[2]: 
https://github.com/dlang/dub/blob/520d527fb11811c8f60b29a0ad15e6f48cf9f9d0/source/dub/internal/utils.d#L263
[3]: 
https://github.com/dlang/dub/blob/1ca0ad263bb364f66f71642152420dd1dce43ce2/source/dub/compilers/compiler.d#L119
[4]: 
https://github.com/dlang/dub/blob/1ca0ad263bb364f66f71642152420dd1dce43ce2/source/dub/dub.d#L1296
[5]: 
https://github.com/dlang/dub/blob/1ca0ad263bb364f66f71642152420dd1dce43ce2/source/dub/generators/build.d#L320


Re: Trouble with LDC2 and definition file to hide console?

2018-08-21 Thread Kagamin via Digitalmars-d-learn
MS has resource compiler too: 
https://docs.microsoft.com/en-us/windows/desktop/menurc/resource-compiler


Re: Trouble with LDC2 and definition file to hide console?

2018-08-21 Thread Kagamin via Digitalmars-d-learn

On Monday, 20 August 2018 at 13:42:58 UTC, spikespaz wrote:
I would also like to know how to add a PNG or ICO file to my 
compiled executable. I have icons in the resolutions of 16, 32, 
64, 128, 256. Currently I'm adding them in using GitHub's 
RCEDIT tool (https://github.com/electron/rcedit) but I would 
like a more proper way.


Compile resource files with windres utility from mingw 
https://sourceware.org/binutils/docs/binutils/windres.html

Example:
--- deflector.rc ---
1 ICON "icon001.ico"
2 ICON "icon002.ico"
3 ICON "icon003.ico"
4 ICON "icon004.ico"
5 ICON "icon005.ico"
6 ICON "icon006.ico"
7 ICON "icon007.ico"
8 ICON "icon008.ico"
9 ICON "icon009.ico"
---

windres deflector.rc deflector.o


Re: D need an ORM library!

2018-08-21 Thread bauss via Digitalmars-d-learn

On Monday, 20 August 2018 at 02:30:16 UTC, binghoo dang wrote:

hi,

I thinks D need an ORM library for Sqlite/Mysql/PostgreSQL, 
entity currently support all the three targets, but entity's 
API is too complex and cumbersome for using.


Is there a more light-weight and simpler implementation like 
ActiveAndroid ?


Thanks!


---

Binghoo Dang


Currently (When I get time again) working on implementing 
PostgreSQL and Sqlite support for Diamond.


Mysql and Mssql should work out the box.

https://github.com/DiamondMVC/Diamond

Some examples will come later, unless you use the latest stable 
version of Diamond then you have examples for MySql, but the 
implementation changes with the next release.


http://diamondmvc.org/docs/data/#database

I wouldn't call it light-weight like you explain, because it does 
have the whole framework, but you could technically just strip 
out the part of compile it with the appropriate flags to exclude 
the parts you don't need like the webserver.


Else take a look at https://github.com/buggins/hibernated and 
perhaps https://github.com/buggins/ddbc is enough.


Re: Deduce type of struct in function arguments

2018-08-21 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 21 August 2018 at 08:32:17 UTC, Seb wrote:



How and where to vote?


At the pull request via +1 and the upcoming "official" 
discussion of the PR.




Except that there's no voting process for DIPs. The Community 
Review is not intended as a way to vote, simply to provide 
feedback on it with the aim of making it a better proposal. I 
know people tend to throw their +1's in there, but I wouldn't 
expect Walter and Andrei to put any weight on that.


Re: Deduce type of struct in function arguments

2018-08-21 Thread Seb via Digitalmars-d-learn

On Tuesday, 21 August 2018 at 06:29:12 UTC, Andrey wrote:

On Monday, 20 August 2018 at 17:45:25 UTC, Seb wrote:
... yet. Though you can vote for this DIP and show your 
support there:


https://github.com/dlang/DIPs/pull/71

It even comes with an implementation in DMD already:

https://github.com/dlang/dmd/pull/8460


How and where to vote?


At the pull request via +1 and the upcoming "official" discussion 
of the PR.


The last discussion was here 
(https://forum.dlang.org/post/lpixarbirhorkltaq...@forum.dlang.org) and it seems there's no clear consensus on the best syntax for this yet :/


Re: D need an ORM library!

2018-08-21 Thread Russel Winder via Digitalmars-d-learn
On Tue, 2018-08-21 at 01:42 +, binghoo dang via Digitalmars-d-learn 
wrote:
[…]
> 
> SQLAlchemy is very great, and I remember that  
> in D wiki has mentioned this, but the status is "Proposed Project 
> Mentors: TBA".

SQLAlchemy is how SQL building and ORM should be done, in Python. For
other programming languages it has to be an inspiration, but not used
as a template for an API – different languages encourage different
idiomatic solutions to the same problem. I know of a C++11 variant that
had the same approach as SQLAlchemy but done in C++1 idiomatic style,
but then I stopped using C++. I haven't looked for a Rust version yet,
but I am hoping one is there.

If there was a D version of SQLAlchemy, that would be wonderful. Feel
free to s/TBA/Russel Winder/

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



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


Cast to original type each argument in template pack

2018-08-21 Thread Andrey via Digitalmars-d-learn

Hello,
I have a function:

string format(string pattern, T...)(T value)
{
   auto writer = appender!string();
   
writer.formattedWrite!pattern(convertToUnderlyingType(value)); 
//Tuple!T(value).expand.to!(OriginalType!T)


   return writer.data;
}


The "value" in this function can be any type including "enum". 
And if it is a "enum" I want to print it's contents not name.
So what I need - check if current argument in template pack is 
enum then convert it in original type. If current argument isn't 
enum - leave it as is. In my example I showed it with imaginary 
function "convertToUnderlyingType".

How to implement it in D?


Re: Generically call a function on Variant's payload?

2018-08-21 Thread Nicholas Wilson via Digitalmars-d-learn
On Monday, 20 August 2018 at 00:27:04 UTC, Nick Sabalausky 
(Abscissa) wrote:
Suppose I've wrapped a Variant in a struct/class which ensures 
the Variant *only* ever contains types which satisfy a 
particular constraint (for example: isInputRange, or hasLength, 
etc...).


Is there a way to call a function (ex: popFront) on the 
Variant, *without* knowing ahead of time all the possible 
static types it might might contain?


I assume you mean at compile time AoT of development of your 
library?


Yes, don't use Variant; use 
https://github.com/s-ludwig/taggedalgebraic





Re: Deduce type of struct in function arguments

2018-08-21 Thread Andrey via Digitalmars-d-learn

On Monday, 20 August 2018 at 17:45:25 UTC, Seb wrote:
... yet. Though you can vote for this DIP and show your support 
there:


https://github.com/dlang/DIPs/pull/71

It even comes with an implementation in DMD already:

https://github.com/dlang/dmd/pull/8460


How and where to vote?


Re: Generically call a function on Variant's payload?

2018-08-21 Thread Nick Sabalausky (Abscissa) via Digitalmars-d-learn

On 08/20/2018 10:57 PM, Jonathan M Davis wrote:


Runtime reflection is theoretically possible in D, but it requires
generating the appropriate stuff for every type involved so that the runtime
stuff has something to work with. Java built all of that into the language
and has the JVM to boot, which fundamentally changes some of what can be
done. With D, we're basically in exactly the same boat as C or C++ except
that we have better compile-time type introspection. In principle, a runtime
reflection facility could be built using that, but even if it were part of
Phobos, it would still have to be opt-in. So, I don't know how useful such a
solution would ever be outside of very specific use cases. Regardless, given
that D's object files, linking, etc. are using the C tools, it was never
going to be the case that Java-style runtime reflection would be built in to
D like it is with Java.


Yea. Not to disagree at all with those reasons, but that is unfortunate. 
I've long been interested in how various features of D (not exclusively 
D, though) combine in ways that, in effect, obsolete much of traditional 
OOP inheritence-based polymorphism - offering the same abilities of OOP 
but without many of the notable downsides. Java-style runtime reflection 
would take us that much further in this regard. (Plus, it would make D 
that much more of a universal-toolbox of a language.) Oh well, dreams vs 
reality ;)