How to check that import module will succeed?
Is there a way to check whether some module, say "foo", is
available for import before doing "import foo"?
I want to create a function that imports module if it's available
or does something else otherwise. So I think the code should look
something like this:
mixin template my_import(alias module_name)
{
if(module_name is available)
mixin("import "~module_name~";");
else
pragma(msg, module_name~" is not available");
}
mixin my_import!("std.stdio"); // == import std.stdio
mixin my_import!("unknown_module"); // == pragma(msg,
"unknown_module is not available")
Re: Is betterC affect to compile time?
On Thursday, 25 July 2019 at 18:37:49 UTC, Jonathan M Davis wrote: There's probably at least one bug report on it, but as I understand it, it's not a bug in the sense that the implementation is currently expected to handle such a case. It's an area where betterC should be improved upon, but it would be an enhancement, not a bug fix. Yes. The point is that libraries have to be written with betterC and compile-time evaluation in mind. If they aren't the code is likely not going to work in those use cases. Much of the code in Phobos was written long before betterC was introduced. There are probably changes that could be made to Phobos so the OP could get a build, but that requires someone with enough interest in the issue to volunteer their time and talent to improve the implementation for betterC and compile-time use cases. We have a GSoC student making changes the druntime to help with this matter and I have been picking away at it too. It will take time and could use more contributors. Mike
Re: Any way to move in @disabled this(this) type in to a wrapping template?
On Thursday, 25 July 2019 at 21:58:06 UTC, aliak wrote: Haha. Ironic. Thanks, again :) Though, if you use auto ref, and you check if it's mutable and not copyable and then move, then that means you could potentially be applying move to an object on behalf of the clients auto a = MyUnmovableType() auto b = LibraryType(a); writeln(a); // ?? If this is a problem, I guess a __traits(isRef, parameter) check along with mutable and copyable could help. Then if client want it moved they could call move explicitly. Yeah, that's why you use core.lifetime.forward instead of directly calling move--it checks all of this stuff for you.
Re: Any way to move in @disabled this(this) type in to a wrapping template?
On Thursday, 25 July 2019 at 21:23:33 UTC, Paul Backus wrote:
On Thursday, 25 July 2019 at 20:38:59 UTC, aliak wrote:
On Thursday, 25 July 2019 at 19:35:36 UTC, aliak wrote:
Basically, can template W be made to handle an S that can't
be copied?
import std;
static struct S {
int i;
@disable this(this);
this(int i) { this.i = i; }
}
[...]
So this works - are there any problems with it?
struct W(T) {
T value;
this(T value) {
static if (isMutable!T)
this.value = value.move;
else
this.value = value;
}
}
auto wrap(T)(T value) {
static if (isMutable!T)
return W!T(value.move);
else
return W!T(value);
}
Shouldn't this be happening by default? When would you not
want that to happen?
The way I handle this is with `auto ref` and
`core.lifetime.forward`:
import core.lifetime: forward;
struct W(T)
{
T value;
this()(auto ref T value)
{
this.value = forward!value;
}
}
auto wrap(T)(auto ref T value)
{
return W!T(forward!value);
}
@safe unittest
{
static struct NoCopy { @disable this(this); }
assert(__traits(compiles, {
auto test = wrap(NoCopy());
}));
assert(!__traits(compiles, {
auto lval = NoCopy(); auto test = lval;
}));
}
Interactive: https://run.dlang.io/is/kDJyYC
It's not very well documented, but `forward` does essentially
the same thing as your `static if` + `move` combination.
Note that with both your version and mine, you will run into
the same problem I did of `move` making it impossible to use
instances of `W` in static initializers and CTFE. [1] The best
compromise I was able to come up with was to only call move if
`isCopyable!T == false`, which doesn't really solve the
problem, but at least contains it.
[1] https://github.com/pbackus/sumtype/issues/22
Haha. Ironic. Thanks, again :)
Though, if you use auto ref, and you check if it's mutable and
not copyable and then move, then that means you could potentially
be applying move to an object on behalf of the clients
auto a = MyUnmovableType()
auto b = LibraryType(a);
writeln(a); // ??
If this is a problem, I guess a __traits(isRef, parameter) check
along with mutable and copyable could help. Then if client want
it moved they could call move explicitly.
Re: Any way to move in @disabled this(this) type in to a wrapping template?
On Thursday, 25 July 2019 at 20:38:59 UTC, aliak wrote:
On Thursday, 25 July 2019 at 19:35:36 UTC, aliak wrote:
Basically, can template W be made to handle an S that can't be
copied?
import std;
static struct S {
int i;
@disable this(this);
this(int i) { this.i = i; }
}
[...]
So this works - are there any problems with it?
struct W(T) {
T value;
this(T value) {
static if (isMutable!T)
this.value = value.move;
else
this.value = value;
}
}
auto wrap(T)(T value) {
static if (isMutable!T)
return W!T(value.move);
else
return W!T(value);
}
Shouldn't this be happening by default? When would you not want
that to happen?
The way I handle this is with `auto ref` and
`core.lifetime.forward`:
import core.lifetime: forward;
struct W(T)
{
T value;
this()(auto ref T value)
{
this.value = forward!value;
}
}
auto wrap(T)(auto ref T value)
{
return W!T(forward!value);
}
@safe unittest
{
static struct NoCopy { @disable this(this); }
assert(__traits(compiles, {
auto test = wrap(NoCopy());
}));
assert(!__traits(compiles, {
auto lval = NoCopy(); auto test = lval;
}));
}
Interactive: https://run.dlang.io/is/kDJyYC
It's not very well documented, but `forward` does essentially the
same thing as your `static if` + `move` combination.
Note that with both your version and mine, you will run into the
same problem I did of `move` making it impossible to use
instances of `W` in static initializers and CTFE. [1] The best
compromise I was able to come up with was to only call move if
`isCopyable!T == false`, which doesn't really solve the problem,
but at least contains it.
[1] https://github.com/pbackus/sumtype/issues/22
Re: Any way to move in @disabled this(this) type in to a wrapping template?
On Thursday, 25 July 2019 at 19:35:36 UTC, aliak wrote:
Basically, can template W be made to handle an S that can't be
copied?
import std;
static struct S {
int i;
@disable this(this);
this(int i) { this.i = i; }
}
struct W(T) {
T value;
this(T value) {
this.value = value;
}
}
auto wrap(T)(T value) {
return W!T(value);
}
void main() {
auto a = wrap(S(3));
}
I tried doing something like:
W!T construct(Args...)(auto ref Args args) {
import std.algorithm: move;
auto value = T(args);
W!T w;
w.value = move(value);
return move(opt);
}
So this works - are there any problems with it?
struct W(T) {
T value;
this(T value) {
static if (isMutable!T)
this.value = value.move;
else
this.value = value;
}
}
auto wrap(T)(T value) {
static if (isMutable!T)
return W!T(value.move);
else
return W!T(value);
}
Shouldn't this be happening by default? When would you not want
that to happen?
Any way to move in @disabled this(this) type in to a wrapping template?
Basically, can template W be made to handle an S that can't be
copied?
import std;
static struct S {
int i;
@disable this(this);
this(int i) { this.i = i; }
}
struct W(T) {
T value;
this(T value) {
this.value = value;
}
}
auto wrap(T)(T value) {
return W!T(value);
}
void main() {
auto a = wrap(S(3));
}
I tried doing something like:
W!T construct(Args...)(auto ref Args args) {
import std.algorithm: move;
auto value = T(args);
W!T w;
w.value = move(value);
return move(opt);
}
Re: Is betterC affect to compile time?
On Thursday, July 25, 2019 8:20:03 AM MDT Ali Çehreli via Digitalmars-d- learn wrote: > On 07/25/2019 05:46 AM, Oleg B wrote: > > On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole wrote: > >> Those restrictions don't stop at runtime. > > > > It's vary sad. > > > > What reason for such restrictions? It's fundamental idea or temporary > > implementation? > > It looks like a bug to me. There's probably at least one bug report on it, but as I understand it, it's not a bug in the sense that the implementation is currently expected to handle such a case. It's an area where betterC should be improved upon, but it would be an enhancement, not a bug fix. - Jonathan M Davis
Re: dip1000, perhaps annotate with return, and vibe-d
On Wednesday, 24 July 2019 at 16:23:48 UTC, Paul Backus wrote:
On Wednesday, 24 July 2019 at 12:54:51 UTC, aliak wrote:
[...]
It should go on the constructor's parameter; i.e.,
this(auto return ref T value) { /* ... */ }
Under the hood, a constructor actually returns the constructed
value by reference, so the actual signature of the above
constructor seen by the lifetime checker is:
ref Optional!T __ctor(auto return ref T value)
You can see this for yourself with something like `pragma(msg,
typeof(Optional!T.__ctor))`.
Thanks! The under the hood stuff was good to know!
I was putting it in the right place but it seems to still have
been complaining. Ah well. I guess an auto ref on a constructor
doesn't really make sense anyway.
Re: Is betterC affect to compile time?
On Thursday, 25 July 2019 at 18:06:02 UTC, Jonathan Marler wrote: On Thursday, 25 July 2019 at 12:46:48 UTC, Oleg B wrote: On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole wrote: Those restrictions don't stop at runtime. It's vary sad. What reason for such restrictions? It's fundamental idea or temporary implementation? Yes it is very sad. It's an implementation thing. I can guess as to a couple reasons why it doesn't work, but I think there's a few big ones that contribute to not being able to use certain features at compile-time without having it introduce things at runtime. Anything you do at compile-time should never produce anything at runtime UNLESS it's a field created or something created using mixin. D's betterC is pretty useless if you can't use D to its fullest at compile-time regardless of whether you're compiling with betterC or not. It takes the one thing away from D that it does better than other languages, which is CTFE and metaprogramming.
Re: Is betterC affect to compile time?
On Thursday, 25 July 2019 at 12:46:48 UTC, Oleg B wrote: On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole wrote: Those restrictions don't stop at runtime. It's vary sad. What reason for such restrictions? It's fundamental idea or temporary implementation? Yes it is very sad. It's an implementation thing. I can guess as to a couple reasons why it doesn't work, but I think there's a few big ones that contribute to not being able to use certain features at compile-time without having it introduce things at runtime.
Re: Is betterC affect to compile time?
On 07/25/2019 05:46 AM, Oleg B wrote: On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole wrote: Those restrictions don't stop at runtime. It's vary sad. What reason for such restrictions? It's fundamental idea or temporary implementation? It looks like a bug to me. Ali
Re: Is betterC affect to compile time?
On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole wrote: Those restrictions don't stop at runtime. It's vary sad. What reason for such restrictions? It's fundamental idea or temporary implementation?
Re: Is betterC affect to compile time?
On 26/07/2019 12:30 AM, Oleg B wrote: On Thursday, 25 July 2019 at 12:20:04 UTC, Mike Franklin wrote: If you read the documentation for betterC (https://dlang.org/spec/betterc.html#consequences) you'll see that there are features of the D language which are not supported. Therefore, libraries that use such features (e.g. std.format, std.array) are also not supported, and that is why you are encountering such errors. There are some features of Phobos which can be used in betterC builds, but you're going to find that it's hit-and-miss. Mike You don't understand my question and don't read code. I ask about compile time evaluation (`format` used inside `mixin` that means it must be computed at compile time). I know that I can't use many features with betterC at runtime. Those restrictions don't stop at runtime.
Re: Is betterC affect to compile time?
On Thursday, 25 July 2019 at 12:20:04 UTC, Mike Franklin wrote: If you read the documentation for betterC (https://dlang.org/spec/betterc.html#consequences) you'll see that there are features of the D language which are not supported. Therefore, libraries that use such features (e.g. std.format, std.array) are also not supported, and that is why you are encountering such errors. There are some features of Phobos which can be used in betterC builds, but you're going to find that it's hit-and-miss. Mike You don't understand my question and don't read code. I ask about compile time evaluation (`format` used inside `mixin` that means it must be computed at compile time). I know that I can't use many features with betterC at runtime.
Re: Is betterC affect to compile time?
On Thursday, 25 July 2019 at 12:01:40 UTC, Oleg B wrote:
Hello everyone!
I try build this code with betterC
import core.stdc.stdio;
import std.format : format;
extern(C) int main()
{
mixin(format!`enum str = "%s\0";`("hello"));
fprintf(stderr, "%s\n", str.ptr);
return 0;
}
but compilation fails
/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6278):
Error: Cannot use try-catch statements with -betterC
/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6308):
Error: template instance
`std.format.checkFormatException!("enum str = \"%s\\0\";",
string)` error instantiating
onlineapp.d(6):instantiated from here: format!("enum
str = \"%s\\0\";", string)
/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6311):
while evaluating: static assert(!e)
/dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3204):
Error: TypeInfo cannot be used with -betterC
Is this a bug?
https://run.dlang.io/is/TG1uhg
If you read the documentation for betterC
(https://dlang.org/spec/betterc.html#consequences) you'll see
that there are features of the D language which are not
supported. Therefore, libraries that use such features (e.g.
std.format, std.array) are also not supported, and that is why
you are encountering such errors.
There are some features of Phobos which can be used in betterC
builds, but you're going to find that it's hit-and-miss.
Mike
Is betterC affect to compile time?
Hello everyone!
I try build this code with betterC
import core.stdc.stdio;
import std.format : format;
extern(C) int main()
{
mixin(format!`enum str = "%s\0";`("hello"));
fprintf(stderr, "%s\n", str.ptr);
return 0;
}
but compilation fails
/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6278):
Error: Cannot use try-catch statements with -betterC
/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6308):
Error: template instance `std.format.checkFormatException!("enum
str = \"%s\\0\";", string)` error instantiating
onlineapp.d(6):instantiated from here: format!("enum str
= \"%s\\0\";", string)
/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6311):
while evaluating: static assert(!e)
/dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3204): Error:
TypeInfo cannot be used with -betterC
Is this a bug?
https://run.dlang.io/is/TG1uhg
Re: How to contact people on the forum
On Wednesday, 24 July 2019 at 16:40:58 UTC, Mike Parker wrote: On Wednesday, 24 July 2019 at 16:37:33 UTC, Greatsam4sure wrote: On Wednesday, 24 July 2019 at 15:56:43 UTC, drug wrote: 24.07.2019 18:51, Greatsam4sure пишет: Good day everyone. I am thinking, if there is a way to contact any person on dlang forums through mail or any other means. How do I get their email from their forum post? I use thunderbird to read the forum and every post contains email of its author, so I would use it to communicate. I don't use thunderbird any other options On the web forum there”s a link labeled “Source” on every post. Click it to see the raw message, including the header which contains the email address. Just be aware that not everyone uses a valid email address. Thanks sir for your reply.
