Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On 04/21/2017 01:20 PM, Vasudev Ram wrote: Hi list, I hope the question is self-evident from the message subject. If not, it means: what are D developers generally called (to indicate that they develop in D)? "Suave, awesome, ultra-attractive programmer with an impeccably fine taste in languages." It's a bit long and doesn't include the letter D, but that just highlights the extreme level of refined, attractive sophistication. (Did I mention attractive?)
Re: Move construction from !is(T == typeof(this))
There is[0] but idk how close it is to std:move and the likes. [0] http://dlang.org/phobos/std_algorithm_mutation.html#.move
Move construction from !is(T == typeof(this))
Are there any known solutions to perform efficient move construction in D?
D's pretty good at doing moves at all the right times, but with a serious
limitation compared to C++ that the type must be an exact match.
Consider this C++; really bad example, but just to illustrate:
struct X { std::string s; };
struct Y {
std::string s;
this(const X &x)
{
s = s; // copy the string, expensive
}
this(X &&x)
{
s = std::move(s); // claim s from x, efficient
}
};
Now, I'm not saying that rval references are the only solution here, just
that I can overload the construction from an X for the rvalue and
non-rvalue case, which is what I want...
I'm thinking in D, this *might* be possible:
struct X {}
struct Y {
this(auto ref X x)
{
static if (__traits(isRef, x))
{
// x is lvalue, copy construct
}
else
{
// x MUST be rvalue(?), move construct
// does this pattern require that I invalidate x the same way C++
does such that X's destructor won't clean up or crash?
}
}
}
Is this solid? I have a vague memory of thinking on this once and realising
there was some edge case where it was logically flawed, but I can't
remember clearly.
Assuming this does work, the next issue is something that mirrors
std::move(), is there already such a thing?
Finally, a further problem exists with auto ref where the function must be
a template. I have cases of code-not-available lib API's where templates
are a problem.
I would prefer to overload 2 constructors for the 2 cases, than have one
template constructor and static if inside. I wonder what would happen in
this case:
struct X {}
struct Y {
this(ref const X x)
{
// x is lvalue reference, copy construct
}
this(X x)
{
// x is an lvalue... which may be a copy of another lvalue. can't move
construct :/
}
}
I guess the question in this case is how overload selection may or may not
work...
I didn't test this, but I expect it's an ambiguous call given an lvalue?
I wonder if this overload set could be made to work such that it is certain
that the non-ref overload is only called with rvalues; ie, given this
ambiguous call, ref is preferred for lvalues. rval can not call ref,
therefore must resolve to byval.
Where is this stuff at?
- Manu
Re: Default-valued nothrow @nogc std.conv:to
On Saturday, 22 April 2017 at 12:14:26 UTC, Nordlöw wrote:
Have anyone tried to implement a variant of `std.conv.to` that
can be `nothrow @nogc` if the exception handling is replaced by
an extra second parameter (`defaultValue`) returned iff the
call to `to` throws?
There is common ifThrown template in Phobos:
https://dlang.org/phobos/std_exception.html#ifThrown
I think it's better to add nothrow ifThrown implementation if
needed.
As for me, for such cases, where input data can be not relevant,
is better to use Nullable type to indicate the error. In this
case, an input value equal to the default value does not cause
problems. Something like this:
import std.typecons: Nullable;
Nullable!T nullableTo(T, S)(S source)
{
import std.conv : to;
tryreturn Nullable!T(source.to!T);
catch(Exception e) return Nullable!T();
}
T orElse(T)(Nullable!T n, T value){ return n.isNull() ? value :
n.get; }
unittest
{
assert(! "0".nullableTo!int.isNull);
assert("0.0".nullableTo!int.isNull);
assert("123.45".nullableTo!int.isNull);
assert("123".nullableTo!int.get == 123);
// And easy convertable to default value variant
assert("123.45".nullableTo!int.orElse(5) == 5);
}
Re: DIP 1005 - Preliminary Review Round 1
On Sunday, 23 April 2017 at 12:03:47 UTC, Andrei Alexandrescu wrote: On 4/22/17 4:52 PM, Joakim wrote: Why is this still up for review? Mostly out of a sense of conformity. We asked Michael to give no special treatment of DIPs originating from us, and this one was open, so he put it up for review. It is likely it will end up rejected in favor of https://github.com/dlang/druntime/pull/1756. The DIP mentions dependency-tracking tools, an important consideration. For both the DIP and the PR it'd be worth identifying if changes will be required in D dependency-tracking tools (dmd/ldc/gdc --deps; rdmd --make-depends) or 3rd party tools in common use. --Jon
Re: DIP 1005 - Preliminary Review Round 1
On Sunday, 23 April 2017 at 19:25:09 UTC, Andrej Mitrovic wrote: With this syntax, the import is executed only if the declared name (process) is actually looked up. I don't believe the workaround with the `from` template fixes this. Not sure what DMD does, but SDC sure would do it only if used.
Re: DIP 1005 - Preliminary Review Round 1
On Sunday, 23 April 2017 at 16:39:35 UTC, deadalnix wrote: It's just one per module. Templates are only instantiated once per new set of arguments. There may be some gain here, but I doubt this is worth adding a new language feature. Ah, good point. Though there's still merit to this DIP such as this: With this syntax, the import is executed only if the declared name (process) is actually looked up. I don't believe the workaround with the `from` template fixes this.
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Saturday, 22 April 2017 at 08:30:03 UTC, Russel Winder wrote: Terms such as Pythonista, Rubyist, Rustacean, Gopher, etc. are terms of tribalism and exclusion. They are attempts to ensure people claiming membership of the tribe reject being polyglot by pressuring them to eschew all other languages. A good programmer can work professionally with a number of languages, the psychology of programming people have data supporting this theory – if the languages have different computational models. Spot on!
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On 04/23/2017 07:55 AM, Guillaume Piolat wrote: On Saturday, 22 April 2017 at 08:30:03 UTC, Russel Winder wrote: Terms such as Pythonista, Rubyist, Rustacean, Gopher, etc. are terms of tribalism and exclusion. They are attempts to ensure people claiming membership of the tribe reject being polyglot by pressuring them to eschew all other languages. +1 When reading such a term I tend to mentally replace it by "beginner" :) I usually read those those terms as "hipster". Similar. :)
Re: Address of UFCS call implicity converts to Delegate
On Sunday, 23 April 2017 at 17:07:51 UTC, Jonathan Marler wrote: On Sunday, 23 April 2017 at 17:00:59 UTC, Basile B. wrote: 2/ Why not just a member function ? For the same reason that UFCS exists. You can't add "member functions" to external library types. Good point. I have to say that this feature then makes me think to what's called "class helpers" in the Delphi/Object Pascal world. That's exactly for what they're used.
Re: Address of UFCS call implicity converts to Delegate
On Sunday, 23 April 2017 at 17:00:59 UTC, Basile B. wrote: 2/ Why not just a member function ? For the same reason that UFCS exists. You can't add "member functions" to external library types.
Re: Address of UFCS call implicity converts to Delegate
On Sunday, 23 April 2017 at 16:32:06 UTC, Jonathan Marler wrote:
This feels like a natural extension to existing semantics. It
doesn't require new syntax and serves as a solution to some
issues when working with delegates.
Say some API wants a delegate like this: void delegate(string
arg)
With this feature, you could take a function like this:
void myCoolFunction(MyClassObject obj, string arg)
{
// ...
}
and the following would have the same delegate type:
&myClassObject.myCoolFunction // type is void delegate(string
arg)
This of course wouldn't work for all functions. The first
parameter of the function would need to have the same calling
convention as the "this" parameter for a "delegate".
void cantBecomeDelegate(SomeBigStructType s)
{
}
&myStruct.cantBecomeDelegate // Error
error: cannot convert UFCS call to delegate because the first
parameter of function 'cantBecomeDelegate' is too large.
Consider adding "ref" to the first parameter or making it a
pointer.
To fix this you could do something like this:
void canBecomeDelegate(ref SomeBigStructType s)
{
}
&myStruct.canBecomeDelegate // OK!
What would be the usage of this ?
Actually i think i see the ABI trick you want to use. And it
works:
==
import std.stdio;
alias ProtoD = void delegate(size_t);
alias ProtoF = void function(size_t);
class Foo{size_t a;}
extern(C) void pseudoMemberFunc(Foo foo, size_t a)
{ foo.a = a;}
void main()
{ Foo foo = new Foo;
// under the hood it's what would make
"&foo.pseudoMemberFunc;"
ProtoD dg;
dg.funcptr = cast(ProtoF) &pseudoMemberFunc;
dg.ptr = cast(void*) foo;
// close the hood carefully
dg(42);
writeln(foo.a);
}
It works in extern(C) only because of parameter order.
==
But:
1/ It's dangerous because then nothing guarantees anymore that
.funcptr is a n actual member function.
2/ Why not just a member function ?
Re: DIP 1005 - Preliminary Review Round 1
On Sunday, 23 April 2017 at 12:03:47 UTC, Andrei Alexandrescu
wrote:
On 4/22/17 4:52 PM, Joakim wrote:
On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote:
DIP 1005 is titled "Dependency-Carrying Declarations".
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md
All review-related feedback on and discussion of the DIP
should occur in this thread. Due to DConf taking place during
the review period, the period will be extended by a week. The
review period will end at 11:59 PM ET on May 13 (3:59 AM GMT
on May 14), or when I make a post declaring it complete.
At the end of Round 1, if further review is deemed necessary,
the DIP will be scheduled for another round. Otherwise,
because the DIP comes from a language author and no formal
review period by the language authors is necessary, the DIP
will be marked "Accepted" or "Rejected" at the author's
discretion.
An extensive discussion regarding this DIP has already taken
place [1].
Thanks in advance to all who participate.
Destroy!
[1]
http://forum.dlang.org/thread/o2psvk$1m96$1...@digitalmars.com?page=1
I thought this DIP was invalidated by the self-important
workaround?
http://forum.dlang.org/post/o72kq8$ggc$1...@digitalmars.com
https://github.com/dlang/druntime/pull/1756#issuecomment-277463742
Why is this still up for review?
Mostly out of a sense of conformity. We asked Michael to give
no special treatment of DIPs originating from us, and this one
was open, so he put it up for review. It is likely it will end
up rejected in favor of
https://github.com/dlang/druntime/pull/1756.
Thanks,
Andrei
this example doenst work with the from!"modName" template, would
it work with dip1005?
module moda;
struct Foo{int i;}
module modb;
void fun(from!"moda".Foo){}
module app;
template test(alias f)
{
mixin("void test(" ~
from!"std.traits".Parameters!f.stringof[1..$-1] ~ "){}");
}
void main()
{
import moda, modb;
test!fun(Foo(5));
}
could dip1005 be introspected?
// you can make the above work with this or is there a better way?
template test(alias f)
{
import traits;
enum paramImports =
{
string res;
foreach(p; Parameters!f)
{
static if(!isBuiltinType!p) res ~= "import " ~
moduleName!p ~ ";\n";
}
return res;
}();
mixin(paramImports);
mixin("void test(" ~ Parameters!f.stringof[1..$-1] ~ "){}");
}
Re: DIP 1005 - Preliminary Review Round 1
On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote: Destroy! I'm not per se against going there but there are 2 points that needs to be considered. The first one is the "self important lookup" which obviate the need for this DIP to some extent. Second, if we are going to proceed anyway, the way this is specified is not ideal. This DIP effectively adds 2 features: 1/ The ability to use import foo as an argument to a with statement. 2/ The introducing of a with declaration in addition of a with statement. These two addition are independents as far as the spec goes and should be kept as such as to avoid an explosion of ad hoc solutions for the use case we want to enable, rather than providing building blocks that combine nicely to build such solutions.
Re: DIP 1005 - Preliminary Review Round 1
On Sunday, 23 April 2017 at 12:34:34 UTC, Andrej Mitrovic wrote: On Sunday, 23 April 2017 at 12:03:47 UTC, Andrei Alexandrescu wrote: Mostly out of a sense of conformity. We asked Michael to give no special treatment of DIPs originating from us, and this one was open, so he put it up for review. It is likely it will end up rejected in favor of https://github.com/dlang/druntime/pull/1756. Wouldn't there be a compile-time performance impact from instantiating so many templates, virtually for every parameter who's type is defined in another module? It's just one per module. Templates are only instantiated once per new set of arguments. There may be some gain here, but I doubt this is worth adding a new language feature.
Address of UFCS call implicity converts to Delegate
This feels like a natural extension to existing semantics. It
doesn't require new syntax and serves as a solution to some
issues when working with delegates.
Say some API wants a delegate like this: void delegate(string arg)
With this feature, you could take a function like this:
void myCoolFunction(MyClassObject obj, string arg)
{
// ...
}
and the following would have the same delegate type:
&myClassObject.myCoolFunction // type is void delegate(string arg)
This of course wouldn't work for all functions. The first
parameter of the function would need to have the same calling
convention as the "this" parameter for a "delegate".
void cantBecomeDelegate(SomeBigStructType s)
{
}
&myStruct.cantBecomeDelegate // Error
error: cannot convert UFCS call to delegate because the first
parameter of function 'cantBecomeDelegate' is too large.
Consider adding "ref" to the first parameter or making it a
pointer.
To fix this you could do something like this:
void canBecomeDelegate(ref SomeBigStructType s)
{
}
&myStruct.canBecomeDelegate // OK!
[OT] Re: DConf 2017 Berlin - bicycles
On Saturday, 22 April 2017 at 01:41:25 UTC, Walter Bright wrote: Many times I idly thought about rigging a sail on my bike. Not a bad idea: https://www.youtube.com/watch?v=AdfE4-hjrWA
Re: Compare boost::hana to D
On 4/23/17 12:22 AM, Jesse Phillips wrote:
On Friday, 21 April 2017 at 13:10:43 UTC, Adam D. Ruppe wrote:
On Wednesday, 19 April 2017 at 18:02:46 UTC, Adrian Matoga wrote:
[2] https://epi.github.io/2017/03/18/less_fun.html
BTW in your D foreach, you could also have done `switch`
void trigger(string event) {
switch(event) {
foreach (i, e; events) {
case e:
foreach (c; callbacks_[i])
c();
return;
}
default:
assert(false, "trying to trigger an unknown event: " ~ event);
}
}
And the compiler+runtime can optimize that into a binary search when
it gets larger automatically.
Doesn't the latest compiler complain with a depreciation that i/e
initialization is being skipped?
Yep, but it's just a warning. A really annoying warning.
https://issues.dlang.org/show_bug.cgi?id=16521 has more details. static
foreach + switch can be bad if you ref the elements of the tuple. The
"correct" thing to do is:
foreach(i, _unused; someTuple)
{
// use someTuple[i] instead of _unused
}
You will still get the warning though.
-Steve
Re: DIP 1005 - Preliminary Review Round 1
On 2017-04-23 14:03, Andrei Alexandrescu wrote: Mostly out of a sense of conformity. We asked Michael to give no special treatment of DIPs originating from us, and this one was open, so he put it up for review. It is likely it will end up rejected in favor of https://github.com/dlang/druntime/pull/1756. Absolutely, that's great. But I would have thought that the DIP would get retracted by the author, or do you still want to see this in the language? -- /Jacob Carlborg
Re: DIP 1005 - Preliminary Review Round 1
On Sunday, 23 April 2017 at 12:03:47 UTC, Andrei Alexandrescu wrote: Mostly out of a sense of conformity. We asked Michael to give no special treatment of DIPs originating from us, and this one was open, so he put it up for review. It is likely it will end up rejected in favor of https://github.com/dlang/druntime/pull/1756. Wouldn't there be a compile-time performance impact from instantiating so many templates, virtually for every parameter who's type is defined in another module?
Re: DIP 1005 - Preliminary Review Round 1
On 4/22/17 4:52 PM, Joakim wrote: On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote: DIP 1005 is titled "Dependency-Carrying Declarations". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md All review-related feedback on and discussion of the DIP should occur in this thread. Due to DConf taking place during the review period, the period will be extended by a week. The review period will end at 11:59 PM ET on May 13 (3:59 AM GMT on May 14), or when I make a post declaring it complete. At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, because the DIP comes from a language author and no formal review period by the language authors is necessary, the DIP will be marked "Accepted" or "Rejected" at the author's discretion. An extensive discussion regarding this DIP has already taken place [1]. Thanks in advance to all who participate. Destroy! [1] http://forum.dlang.org/thread/o2psvk$1m96$1...@digitalmars.com?page=1 I thought this DIP was invalidated by the self-important workaround? http://forum.dlang.org/post/o72kq8$ggc$1...@digitalmars.com https://github.com/dlang/druntime/pull/1756#issuecomment-277463742 Why is this still up for review? Mostly out of a sense of conformity. We asked Michael to give no special treatment of DIPs originating from us, and this one was open, so he put it up for review. It is likely it will end up rejected in favor of https://github.com/dlang/druntime/pull/1756. Thanks, Andrei
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Saturday, 22 April 2017 at 08:30:03 UTC, Russel Winder wrote: Terms such as Pythonista, Rubyist, Rustacean, Gopher, etc. are terms of tribalism and exclusion. They are attempts to ensure people claiming membership of the tribe reject being polyglot by pressuring them to eschew all other languages. +1 When reading such a term I tend to mentally replace it by "beginner" :)
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Saturday, 22 April 2017 at 08:30:03 UTC, Russel Winder wrote: Terms such as Pythonista, Rubyist, Rustacean, Gopher, etc. are terms of tribalism and exclusion. They are attempts to ensure people claiming membership of the tribe reject being polyglot by pressuring them to eschew all other languages. A good programmer can work professionally with a number of languages, the psychology of programming people have data supporting this theory – if the languages have different computational models. Agreed. No need to praise your own group while ridiculing others. These are programming languages, not text editors.
Re: [OT] do we have lint for bash?
On Sunday, 23 April 2017 at 10:07:30 UTC, cym13 wrote: On Sunday, 23 April 2017 at 09:51:36 UTC, Kagamin wrote: https://abload.de/img/tmpliy6q.png I guess you're looking for something like http://www.shellcheck.net/ However I don't see how an automated tool could have found the error in your screenshot as passing multiple arguments to rm is a perfectly reasonnable thing. Maybe it could have suggested to put quotes which would have helped though. It's too peculiar to be expected from a generic tool though IMHO. ShellCheck does catch that. https://github.com/koalaman/shellcheck/wiki/SC2114
Re: [OT] do we have lint for bash?
On Sunday, 23 April 2017 at 09:51:36 UTC, Kagamin wrote: https://abload.de/img/tmpliy6q.png I guess you're looking for something like http://www.shellcheck.net/ However I don't see how an automated tool could have found the error in your screenshot as passing multiple arguments to rm is a perfectly reasonnable thing. Maybe it could have suggested to put quotes which would have helped though. It's too peculiar to be expected from a generic tool though IMHO.
[OT] do we have lint for bash?
https://abload.de/img/tmpliy6q.png
template auto switch_(Any& a) { return [&a](auto ...cases_) { auto cases = hana::make_tuple(cases_...); auto default_ = hana::find_if(cases, [](auto const& c) { return hana:
template
auto switch_(Any& a) {
return [&a](auto ...cases_) {
auto cases = hana::make_tuple(cases_...);
auto default_ = hana::find_if(cases, [](auto const& c) {
return hana::first(c) == hana::type_c;
});
// ...
};
}
