Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 05:39:05 UTC, Mike Franklin wrote: I understand that Walter's DIPs have been put through the process just like the others, but with regard to the specific issue in this thread (https://issues.dlang.org/show_bug.cgi?id=19097), the accompanying PR (https://github.com/dlang/dmd/pull/8504), and similarly undocumented PR (https://github.com/dlang/dmd/pull/8408), they are amending DIP 1000 and DIP 25 "under the table". There is no accompanying PR to the specification, no formal rational, no RFC from the community, etc... A 3rd example (https://github.com/dlang/dmd/pull/8346) to throw a little more salt on the wound. The DIP25/1000 rabbit hole is deepening behind the curtain. Mike
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 05:04:25 UTC, Mike Parker wrote: Whatever the status of DIP 1000, I would point out that that one of Walter's DIPs is in Community Review right now after sitting in the PR queue in Draft Review for a while. Once this review stage is done, it will go back into the queue to await Final Review like any other DIP. The only difference between this and other DIPs is that there will be no Formal Assessment for it. And this is the second DIP from Walter that has gone through the process since I've come on board, with DIP 1008 being put on pause at his request. I understand that Walter's DIPs have been put through the process just like the others, but with regard to the specific issue in this thread (https://issues.dlang.org/show_bug.cgi?id=19097), the accompanying PR (https://github.com/dlang/dmd/pull/8504), and similarly undocumented PR (https://github.com/dlang/dmd/pull/8408), they are amending DIP 1000 and DIP 25 "under the table". There is no accompanying PR to the specification, no formal rational, no RFC from the community, etc... Yet I and others have to go through the DIP process for much less significant changes to the language, and rightly so: https://github.com/dlang/dmd/pull/7310 https://github.com/dlang/dmd/pull/7079 All I want to see from Walter is: 1) a sufficiently documented proposal for his idea 2) an RFC from the community 3) a PR to the spec documenting the final design I don't think that's too much to ask. Mike
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 04:49:15 UTC, Mike Franklin wrote: It is hypocritical an arrogant to believe that only our ideas have flaws and require scrutiny. Sorry, that was poorly stated and conveyed the wrong intent. It should read: It is hypocritical an arrogant to believe that only our ideas should require thorough documentation and scrutiny. Mike
Re: Engine of forum
On Tuesday, 21 August 2018 at 22:00:31 UTC, Jesse Phillips wrote: On Tuesday, 21 August 2018 at 19:25:14 UTC, Walter Bright wrote: With the NNTP, git, and bugzilla, we all have backups under our control. I just don't see why it is a concern[1]: "So we set out to look for a new home for our data dumps, and today we’re happy to announce that the Internet Archive has agreed to host them: The Stack Exchange Data Dump at the Internet Archive[2]" 1. : https://stackoverflow.blog/2014/01/23/stack-exchange-cc-data-now-hosted-by-the-internet-archive/ 2. https://archive.org/details/stackexchange The dlang bugzilla and forum are both hosted on dlang-specific servers. If they go down, it's easy to get a replica and get back up and running in a few hours. Same with the wiki. If github went down or banned the dlang org, we'd lose in-progress pull requests and the history of pull request comments. Aside from that, we would be up and running on gitlab or what have you in hours. If Stack Overflow went down, we'd have to find an alternative, and then we'd have to figure out how to import that data. That could take weeks. And it will happen eventually.
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 02:18:15 UTC, Mike Franklin wrote: Furthermore, I find it hypocritical that some of us are put through a disproportionately burdensome DIP process requiring thorough documentation, multiple peer reviews, excessive delays, and judgement that defaults to "no" for some of the most minute changes to the language, but a game-changing feature like DIP 1000 can just be amended on a whim. DIP 1000 is in a bit of limbo at the moment. When I took over the process from Mihails, he told me it was stalled and that the proposal did not match the implementation. So I haven't touched it, which is why it's still marked as Draft. At some point, Walter will revise it to match the implementation and then we'll discuss how to handle it. Whatever the status of DIP 1000, I would point out that that one of Walter's DIPs is in Community Review right now after sitting in the PR queue in Draft Review for a while. Once this review stage is done, it will go back into the queue to await Final Review like any other DIP. The only difference between this and other DIPs is that there will be no Formal Assessment for it. And this is the second DIP from Walter that has gone through the process since I've come on board, with DIP 1008 being put on pause at his request.
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 04:23:52 UTC, Jonathan M Davis wrote: The reality of the matter is that the DIP system is a formal way to propose language changes in order to convince Walter and Andrei that those changes should be implemented, whereas if Walter or Andrei writes the DIP, they're already convinced. This isn't a democracy. Walter is the BDFL, and it's his call. So, I really don't think that it's hypocritical Walter and Andrei need to have their ideas vetted by the community, not in an effort to convince anyone, but for quality assurance, to ensure they're not overlooking something. It is hypocritical an arrogant to believe that only our ideas have flaws and require scrutiny. Mike
Re: Deduce type of struct in function arguments
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: Is @safe still a work-in-progress?
On Tuesday, August 21, 2018 8:18:15 PM MDT Mike Franklin via Digitalmars-d wrote: > On Wednesday, 22 August 2018 at 01:07:28 UTC, Mike Franklin wrote: > > But what bothers me the most... > > Something else that rubs me the wrong way is that DIP 1000 is > currently in a status of `DRAFT`: > https://github.com/dlang/DIPs/blob/master/DIPs/README.md > > What the heck is going on here? We're adding features to the > compiler and modifying Phobos in production releases based on a > `DRAFT` proposal? > > Furthermore, I find it hypocritical that some of us are put > through a disproportionately burdensome DIP process requiring > thorough documentation, multiple peer reviews, excessive delays, > and judgement that defaults to "no" for some of the most minute > changes to the language, but a game-changing feature like DIP > 1000 can just be amended on a whim. The reality of the matter is that the DIP system is a formal way to propose language changes in order to convince Walter and Andrei that those changes should be implemented, whereas if Walter or Andrei writes the DIP, they're already convinced. This isn't a democracy. Walter is the BDFL, and it's his call. So, I really don't think that it's hypocritical, but I also do think that DIP 1000 probably should have gone through more peer review. From what I can tell, outside of the simple cases, pretty much everyone has a really hard time understanding it. The situation will likely improve once Phobos properly supports it, and you can more reasonably use it, but the whole thing defnitely seems to be overly complicated given what it's supposed to be doing and what benefits you get from it. Personally, I think that it seems pretty reasonable as long as user-defined types don't get involved, but once they do, it's a mess. - Jonathan M Davis
Re: Is @safe still a work-in-progress?
On Tuesday, 21 August 2018 at 14:31:02 UTC, Atila Neves wrote: The problem is that the code we write doesn't deal directly with pointers - see the recent confusion in this forum over where `scope` on the left applies to the `this` pointer or the one returned by the member function. Kagamin just told me I needed to use `return` instead of `scope` to get things to work and I'm still not sure why. The way I think about it is if you have a function that takes a pointer, any pointer, and either returns it or a pointer derived from it (dereferencing or indexing) that argument must be marked `return`. In your case it was a pointer derived from `this` so `return` must be applied to `this`.
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 01:07:28 UTC, Mike Franklin wrote: But what bothers me the most... Something else that rubs me the wrong way is that DIP 1000 is currently in a status of `DRAFT`: https://github.com/dlang/DIPs/blob/master/DIPs/README.md What the heck is going on here? We're adding features to the compiler and modifying Phobos in production releases based on a `DRAFT` proposal? Furthermore, I find it hypocritical that some of us are put through a disproportionately burdensome DIP process requiring thorough documentation, multiple peer reviews, excessive delays, and judgement that defaults to "no" for some of the most minute changes to the language, but a game-changing feature like DIP 1000 can just be amended on a whim. Mike
Re: D support for ChromeOS
On Wednesday, 22 August 2018 at 01:48:01 UTC, Joakim wrote: On Tuesday, 21 August 2018 at 20:29:34 UTC, Emil wrote: On Saturday, 3 February 2018 at 18:11:15 UTC, Daniel Kozak wrote: [...] Tried it on an Acer Chromebook R13 running Version 69.0.3497.35 (Official Build) dev (32-bit). I have no previous experience with llvm. [...] Looks like your Chromebook's got a MediaTek AArch64 processor, ie 64-bit ARM, which wasn't supported by D until the just released LDC 1.11. I'd try building 1.11 from source, using these instructions: https://wiki.dlang.org/Building_LDC_from_source You will need a working CMake though, looks like the one you're trying to use isn't running. Oh, I forgot, if you're running Android apps in your Chromebook, you can install the Termux app and use LDC through there: https://play.google.com/store/apps/details?id=com.termux=en The first AArch64 build of LDC for Termux should be up in a day or so, `apt install ldc`, or you can build it from source in Termux, if you can't wait. ;)
Re: D support for ChromeOS
On Tuesday, 21 August 2018 at 20:29:34 UTC, Emil wrote: On Saturday, 3 February 2018 at 18:11:15 UTC, Daniel Kozak wrote: [...] Tried it on an Acer Chromebook R13 running Version 69.0.3497.35 (Official Build) dev (32-bit). I have no previous experience with llvm. [...] Looks like your Chromebook's got a MediaTek AArch64 processor, ie 64-bit ARM, which wasn't supported by D until the just released LDC 1.11. I'd try building 1.11 from source, using these instructions: https://wiki.dlang.org/Building_LDC_from_source You will need a working CMake though, looks like the one you're trying to use isn't running.
Re: Is @safe still a work-in-progress?
On Tuesday, 21 August 2018 at 21:17:25 UTC, Atila Neves wrote: I don't have merge rights. I took a look anyway and it mostly looks ok, but I'm not familiar enough with that part of the codebase. It's not the implementation that's preventing it from being merged. It's the idea itself, weak rationale, lack of peer review, lack of consideration for alternatives, and lack of documentation supporting it. It reeks of "designed on a whim to quickly patch some oversight in the design DIP1000 while trying to get Phobos to compile with -dip1000". With the proposed idea, order of parameters matters. We'll need to establish a convention that return parameters must be declared first, which is opposite of https://dlang.org/phobos/std_algorithm_mutation.html#copy. Is that a good idea? Maybe it is. We haven't vetted the design yet, so I'm not sure. Why haven't we vetted the design? Because there currently isn't one; there's just an informal back-of-the-napkin memo uploaded to a bugzilla entry. The proposed idea wants to make the first parameter, if it's `ref`, special. Why not the first `ref` parameter regardless of whether it's the absolute first in the list. Why not the last `ref` parameter? Why not all `ref` parameters? But what bothers me the most is I think it's missing the bigger picture: D needs a way to annotate lifetimes. Maybe `scope` and `return` with weird conditions based on the order of parameters and their attributes are the way to go. Maybe there's another way that hasn't yet been considered. Put together a thorough description of the proposal, justify it, ask the larger community for comment, vet it, and document it. At least that's what it's going to take to get me to take action on the PR. Or maybe someone else is willing to just rubber stamp it in the interest of expediency. Mike
Re: Deduce type of struct in function arguments
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.
[Issue 19097] Extend Return Scope Semantics
https://issues.dlang.org/show_bug.cgi?id=19097 --- Comment #9 from Mike Franklin --- (In reply to Steven Schveighoffer from comment #8) > Just because Phobos follows the convention of putting the "return" parameter > as the first parameter, does that mean the language should require it? I don't think that's necessarily true. Take a look at https://dlang.org/phobos/std_algorithm_mutation.html#copy `TargetRange copy(SourceRange, TargetRange)(SourceRange source, TargetRange target)` Is copy an exception? I recently asked about this convention at https://github.com/dlang/druntime/pull/2264#pullrequestreview-143076892 --
Re: Coreect way to create delegate for struct method.
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();
}
´´´
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #9 from ag0aep6g ---
(In reply to Atila Neves from comment #8)
> > @safe code can mess with it
>
> No it can't, that's the point of @safe. Mess with it how?
@safe applies to functions/methods, not variables/fields. You can't forbid
@safe code from accessing a visible variable.
Example that's similar to your code:
int x = 41;
int y = 42;
struct S
{
int* p;
void t() @trusted
{
import core.stdc.stdlib: malloc;
if (p is null) p = cast(int*) malloc(2 * int.sizeof);
p[1] = 13;
}
void s() @safe { p = }
}
void main() @safe
{
S s;
s.s();
s.t();
assert(y == 42); /* Fails. */
}
Here, `t` assumes that `p` will be the result of `malloc`. But there is no way
in the language to force @safe code to respect that assumption. You can always
add an @safe method like `s` that messes with `p`, and then `t` will violate
safety.
DIP 1000 doesn't help here. It doesn't add a mechanism with which we could make
`p` inaccessible from `s`.
We're drifting off-topic topic here, though. Maybe we should move it to the
forum if we're not on the same page by now?
[...]
> --
> @safe:
>
> const(int)* gInts;
>
> void main() {
> auto s = MyStruct();
> gInts = s.ptr;
> }
>
> struct MyStruct {
> int* ints;
> scope ptr(this This)() { return ints; }
> }
> --
You're still just copying an `int*` around, which isn't unsafe. `ptr` is
inferred as `return` so it's allowed to return `ints`. I suppose your point is
that `return` shouldn't be inferred? Maybe, but it's not obvious from the code.
A test case that shows actual damage (memory corruption) would go a long way.
[...]
> Because, from DIP1000:
>
> A variable is inferred to be scope if it is initialized with a value that
> has a non-∞ lifetime.
Without `scope` on the variable and without a destructor, there is no
indication that `s.ints` has a non-infinite lifetime.
> This very same code without a template this and instead manual
> instantiations of the three versions (mutable, const, immutable) doesn't
> compile _even_ if `auto` is used in the variable declaration.
I'm not sure if I understand that correctly, but this compiles just fine:
@safe:
const(int)* gInts;
void main() {
auto s = MyStruct();
gInts = s.ptr;
}
struct MyStruct {
int* _ints;
auto ptr() { return _ints; }
auto ptr() const { return _ints; }
auto ptr() immutable { return _ints; }
}
> Furthermore, if `auto` was enough to get away from compiler checks, DIP1000
> would be useless since nobody is going to remember to write `scope`.
Copying a pointer isn't unsafe. There's no reason for the compiler to reject it
unless you add further restrictions by using `scope`.
--
Re: Engine of forum
On Tuesday, 21 August 2018 at 19:25:14 UTC, Walter Bright wrote: With the NNTP, git, and bugzilla, we all have backups under our control. I just don't see why it is a concern[1]: "So we set out to look for a new home for our data dumps, and today we’re happy to announce that the Internet Archive has agreed to host them: The Stack Exchange Data Dump at the Internet Archive[2]" 1. : https://stackoverflow.blog/2014/01/23/stack-exchange-cc-data-now-hosted-by-the-internet-archive/ 2. https://archive.org/details/stackexchange
Re: Engine of forum
On Tuesday, 21 August 2018 at 21:33:13 UTC, Patrick Schluter wrote: On Tuesday, 21 August 2018 at 06:53:18 UTC, Daniel N wrote: On Tuesday, 21 August 2018 at 03:42:21 UTC, Ali wrote: Many of those new comers who ask about the forum software .. they never stick, they dont complain, or question, or try to change for the better, they simply leave I think this is the best forum I have ever used, it's a big contributing factor to that I post here! I don't post every month praising the forum, I'm silently happy. But if we changed I would likely complain every month. Second that. The 2 big things this forum frontend has, is forcing to snip quotes (go look on realworldtech to see whole threads of quote galore of 400 lines where the answer is just one word) and speed. The thing that comments cannot be edited is also an advantage. This forces to put a little be more thought in them. What about if you accidentially press a button that posts the comment? Why can't syntax formatting be implemented, does anyone disagree that is a useless feature?
Re: Are properties mature enough?
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
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: Engine of forum
On Tuesday, 21 August 2018 at 06:53:18 UTC, Daniel N wrote: On Tuesday, 21 August 2018 at 03:42:21 UTC, Ali wrote: Many of those new comers who ask about the forum software .. they never stick, they dont complain, or question, or try to change for the better, they simply leave I think this is the best forum I have ever used, it's a big contributing factor to that I post here! I don't post every month praising the forum, I'm silently happy. But if we changed I would likely complain every month. Second that. The 2 big things this forum frontend has, is forcing to snip quotes (go look on realworldtech to see whole threads of quote galore of 400 lines where the answer is just one word) and speed. The thing that comments cannot be edited is also an advantage. This forces to put a little be more thought in them.
Re: Generically call a function on Variant's payload?
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.
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #8 from Atila Neves ---
> @safe code can mess with it
No it can't, that's the point of @safe. Mess with it how?
> Why shouldn't this compile? There's no `scope` anywhere now (except maybe an
> inferred one)
Function template => inferred attributes => scope. But fine, this compiles and
shouldn't:
--
@safe:
const(int)* gInts;
void main() {
auto s = MyStruct();
gInts = s.ptr;
}
struct MyStruct {
int* ints;
scope ptr(this This)() { return ints; }
}
--
> This makes sense to me. With `s` being `scope`, the compiler now checks it
> and its contents don't leave `main`.
Because, from DIP1000:
A variable is inferred to be scope if it is initialized with a value that has a
non-∞ lifetime.
This very same code without a template this and instead manual instantiations
of the three versions (mutable, const, immutable) doesn't compile _even_ if
`auto` is used in the variable declaration.
Furthermore, if `auto` was enough to get away from compiler checks, DIP1000
would be useless since nobody is going to remember to write `scope`.
--
Coreect way to create delegate for struct method.
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: Is @safe still a work-in-progress?
On Tuesday, 21 August 2018 at 19:36:39 UTC, Walter Bright wrote:
On 8/21/2018 7:31 AM, Atila Neves wrote:
The problem is that the code we write doesn't deal directly
with pointers - see the recent confusion in this forum over
where `scope` on the left applies to the `this` pointer or the
one returned by the member function.
That's what I was saying :-)
The way to deal with this is make a copy of the code, then
rewrite it so it does the exact same thing, but with pointers
and refs only. No member functions, no delegates, no dynamic
arrays. Then it is MUCH MUCH easier to see where the
annotations go.
Well, no. The syntax isn't the same for member functions. The
examples from the actual DIP don't compile. There it says:
---
scope can be applied to function return values (even though it is
not a type qualifier). It must be applied to the left of the
declaration, in the same way ref is:
scope int* foo(); // applies to return value
Except:
---
struct MyStruct { scope int* foo() scope; }
foo.d(1): Error: redundant attribute scope
---
Meaning the first `scope` actually applies to `this`. Writing
this out as a non-member function won't help me declare member
functions!
I still don't know how to return a ref/pointer that's scoped. And
I thought I'd written code that did that. Maybe I did. I'm very
confused.
BTW, the annotations do not break things. The worst that will
happen is the compiler will complain in @safe code that they
are incorrect, and you'll need to fix it or make it @trusted.
The compiler is also pretty good about inferring the correct
annotations, at least for templates and lambdas, which helps
enormously.
In my opinion, the worst that can happen is I successfully
compile my @safe code with -dip1000 and the resulting binary
isn't memory-safe, which is what's been happening to me.
However, dip1000 not working with Phobos is a huge impediment
to success, and so pulling 8504 is critical.
I don't have merge rights. I took a look anyway and it mostly
looks ok, but I'm not familiar enough with that part of the
codebase.
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #7 from ag0aep6g ---
(In reply to Atila Neves from comment #6)
> What's @trusted is that I'm calling `free` on the same pointer I allocated
> in the constructor, and the other thing needing checking is the postblit.
If you want to keep the @trusted promise, you can't rely on the pointer being
the same. @safe code can mess with it. There's no way around that. Maybe there
should be.
So what you do is this: You mark the `free` call as @trusted anyway, because
there's no other way. And then you have to check manually that your @safe code
doesn't mess with the pointer. Ideally, manual checks wouldn't be needed for
@safe code, but that's the price you pay for breaking the @trusted promise.
> This all is besides the point, given the code below has no @trusted
> anywhere, compiles, and shouldn't:
>
> ---
> @safe:
>
> const(int)* gInts;
>
> void main() {
> auto s = MyStruct();
> gInts = s.ptr;
> }
>
> struct MyStruct {
> int* _ints;
> auto ptr(this This)() { return _ints; }
> }
> ---
Why shouldn't this compile? There's no `scope` anywhere now (except maybe an
inferred one). You're just copying an `int*` around. That's not against any
rules.
> As in the original report:
>
>
> * Adding a no-op destructor does nothing (i.e. the code still compiles):
>
> ~this() {} // ok but shouldn't be
Why shouldn't it compile with the destructor? The destructor is marked as @safe
and does nothing. So it's the same as not having a destructor at all, no?
> * Adding a no-op destructor annotate with scope causes a compile-time error:
>
> ~this() scope { }
>
> baz.d(7): Error: scope variable s assigned to gInts with longer lifetime
Interesting. Looks like a `scope` destructor also makes any instances
implicitly `scope`. I don't think I understand DIP 1000 or its implementation
well enough to this. DIP 1000 doesn't seem to mention it, as far as I see.
> * With no destructor at all but replacing `auto` with `scope` also fails to
> compile:
>
> scope s = MyStruct();
>
> baz.d(7): Error: scope variable s assigned to gInts with longer lifetime
This makes sense to me. With `s` being `scope`, the compiler now checks it and
its contents don't leave `main`.
If `s` is not `scope`, there's no indication that its contents shouldn't be
allowed to leave `main`.
> Weirdly enough, changing `gInts` to a static array and returning &_ints[0]
> in ptr also fails to compile;
Do you mean making `_ints` a static array (e.g., `int[1] _ints;`)? If so, the
code effectively becomes:
const(int)* gInts;
void main() @safe
{
int _ints;
gInts = &_ints;
}
Leaking a reference to a local variable is not allowed, of course. It's very
different from copying a pointer.
If you really mean making `gInts` a static array, could you post the full code?
I don't understand what you mean in that case.
--
Re: D support for ChromeOS
On Saturday, 3 February 2018 at 18:11:15 UTC, Daniel Kozak wrote: Today I have added basic support for D language (ldc and dub) to chromebrew: https://github.com/skycocker/chromebrew/pull/1717 So if you have ChromeBook with Chrome OS (developer mode is needed for chromebrew), you can try it, if everything works ok for you. Tried it on an Acer Chromebook R13 running Version 69.0.3497.35 (Official Build) dev (32-bit). I have no previous experience with llvm. dub init ran fine. getting this error when trying to run dub in the newly created project chronos@localhost ~/work/my_test $ dub Failed to invoke the compiler /usr/local/bin/ldc2 to determine the build platform: /usr/local/bin/ldc2: error while loading shared libraries: libLLVMLTO.so.5: cannot open shared object file: No such file or directory when running ldc2 chronos@localhost ~/work/my_test $ ldc2 ldc2: error while loading shared libraries: libLLVMLTO.so.5: cannot open shared object file: No such file or directory I do have another version installed though: chronos@localhost ~/work/my_test $ locate libLLVMLTO /mnt/stateful_partition/dev_image/lib/libLLVMLTO.so /mnt/stateful_partition/dev_image/lib/libLLVMLTO.so.6 /mnt/stateful_partition/dev_image/lib/libLLVMLTO.so.6.0.0 /usr/local/lib/libLLVMLTO.so /usr/local/lib/libLLVMLTO.so.6 /usr/local/lib/libLLVMLTO.so.6.0.0 trying to build ldc: chronos@localhost ~/work/my_test $ crew build ldc (i) ldc: D language compiler using LLVM. https://github.com/ldc-developers/ldc version 1.7.0 Downloading source... Archive downloaded Unpacking archive, this may take awhile... Building from source, this may take a while... Rename all *.la files to *.la_tmp % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total Spent Left Speed 100 6100 6100 0742 0 --:--:-- --:--:-- --:--:-- 778 100 4888k 100 4888k0 0 437k 0 0:00:11 0:00:11 --:--:-- 749k cmake: /usr/lib/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by cmake) cmake: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by cmake) cmake: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by cmake) ldc failed to build: `cmake -Bbuild/ldc-0.17.5-src -Hbuild/ldc-0.17.5-src` exited with 1 chronos@localhost ~/work/my_test $ uname -a Linux localhost 3.18.0-18117-g8dfac4fe62f3 #1 SMP PREEMPT Fri Aug 10 09:50:22 PDT 2018 aarch64 ARMv8 Processor rev 2 (v8l) GNU/Linux chronos@localhost ~/work/my_test $ cat /proc/cpuinfo processor : 0 model name : ARMv8 Processor rev 2 (v8l) Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part: 0xd03 CPU revision: 2
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #6 from Atila Neves ---
I typed the code from memory and made a mistake. Yes, it's supposed to be
`.ptr`. There's no way I can call core.stdc.stdlib.free without @trusted
_somewhere_, since `free` isn't @safe - free(42) is obviously going to crash.
What's @trusted is that I'm calling `free` on the same pointer I allocated in
the constructor, and the other thing needing checking is the postblit.
This all is besides the point, given the code below has no @trusted anywhere,
compiles, and shouldn't:
---
@safe:
const(int)* gInts;
void main() {
auto s = MyStruct();
gInts = s.ptr;
}
struct MyStruct {
int* _ints;
auto ptr(this This)() { return _ints; }
}
---
As in the original report:
* Adding a no-op destructor does nothing (i.e. the code still compiles):
~this() {} // ok but shouldn't be
* Adding a no-op destructor annotate with scope causes a compile-time error:
~this() scope { }
baz.d(7): Error: scope variable s assigned to gInts with longer lifetime
* With no destructor at all but replacing `auto` with `scope` also fails to
compile:
scope s = MyStruct();
baz.d(7): Error: scope variable s assigned to gInts with longer lifetime
Weirdly enough, changing `gInts` to a static array and returning &_ints[0] in
ptr also fails to compile;
--
[Issue 19097] Extend Return Scope Semantics
https://issues.dlang.org/show_bug.cgi?id=19097 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #8 from Steven Schveighoffer --- Just throwing this out there, why do we need it to be the first parameter? Why not ALL ref parameters? It makes sense for a constructor, for which there is an obvious return expectation of the `this` parameter, but anyone can devise some calling scheme by which any arguments are transferred to any other ref arguments. Just because Phobos follows the convention of putting the "return" parameter as the first parameter, does that mean the language should require it? --
Re: Are properties mature enough?
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
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
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: Is @safe still a work-in-progress?
On 8/21/2018 7:31 AM, Atila Neves wrote: The problem is that the code we write doesn't deal directly with pointers - see the recent confusion in this forum over where `scope` on the left applies to the `this` pointer or the one returned by the member function. That's what I was saying :-) The way to deal with this is make a copy of the code, then rewrite it so it does the exact same thing, but with pointers and refs only. No member functions, no delegates, no dynamic arrays. Then it is MUCH MUCH easier to see where the annotations go. Kagamin just told me I needed to use `return` instead of `scope` to get things to work and I'm still not sure why. Also: destructors? Always `scope`? Sometimes? I just add `scope` when the compiler complains at this point. I think it's interesting that when I played with Rust I didn't have problems fighting the borrow checker at all. DIP1000 is supposed to have the same safety without the Rust complications but currently Rust is much easier to understand for me. It doesn't help that the current implementation of -dip1000 doesn't match the document it's supposedly based on. All good points. But I cannot make any progress when nobody is willing to pull my PRs that improve the situation. https://github.com/dlang/dmd/pull/8504 BTW, the annotations do not break things. The worst that will happen is the compiler will complain in @safe code that they are incorrect, and you'll need to fix it or make it @trusted. The compiler is also pretty good about inferring the correct annotations, at least for templates and lambdas, which helps enormously. However, dip1000 not working with Phobos is a huge impediment to success, and so pulling 8504 is critical.
Re: Engine of forum
On 8/21/2018 7:18 AM, Seb wrote: some rely on stackoverflow, some have an active wiki There are a few good points to move D.learn to Stack Overflow and that's actually one thing that we have talked about a few times and somehow never has happened. In the D survey there was a 2:1 "consensus" for StackOverflow. My reservation about stackoverflow is it could go dark at any moment, and we'd lose it all. Having critical business data dependent on any third party that has zero commitment or accountability to us is very risky. With the NNTP, git, and bugzilla, we all have backups under our control.
Re: Generically call a function on Variant's payload?
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
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #5 from ag0aep6g ---
(In reply to Atila Neves from comment #4)
> I made a mistake when I posted the code. This compiles but shouldn't (the
> only difference is removing `scope` from the destructor).
[...]
> @safe:
>
> const(int)* gInts;
>
> void main() {
> auto s = MyStruct(10);
> gInts = s.ints;
> }
>
> struct MyStruct
> {
> import core.stdc.stdlib;
> int* ints;
> this(int size) @trusted { ints = cast(int*) malloc(size); }
> ~this() { () @trusted { free(ints); }(); }
> scope ptr(this This)() { return ints; }
> }
You're not calling `ptr`. `main` reads the `ints` field directly. That's
allowed, of course. D has no way of preventing @safe code from accessing a
local struct's field.
If the code is changed to actually call `ptr`, it still compiles. Maybe that
shouldn't be allowed, but it's not obvious to me from the code. If this is a
safety violation, we should be able to show something like memory corruption,
mutating immutable data, stuff like that.
As it is, the only obvious safety violation is in the @trusted destructor. It
assumes that the `ints` field is not accessible from @safe code, but that's
wrong. Unfortunately, misusing @trusted like that is necessary for stuff like
this, but it still means breaking the @trusted promise. The consequence is that
(at least) the whole module must be checked manually to uphold the assumption
of the badly @trusted method. One cannot rely on @safe to catch mistakes in
that area. So if none of MyStruct's methods can be allowed to return `ints`,
because the destructor relies on that, then that must be checked manually.
--
Re: D, Parasail, Pascal, and Rust vs The Steelman
On Wednesday, 21 March 2018 at 16:08:07 UTC, Martin Tschierschke wrote: On Wednesday, 21 March 2018 at 12:52:19 UTC, Paulo Pinto wrote: An article comparing the above languages as per the DoD language requirements [0]. http://jedbarber.id.au/steelman.html [0] - https://en.wikipedia.org/wiki/Steelman_language_requirements Interesting! Do you understand this: 7H. Formal Array Parameters. The number of dimensions for formal array parameters must be specified in programs and shall be determinable during translation. Determination of the subscript range for formal array parameters may be delayed until invocation and may vary from call to call. Subscript ranges shall be accessible within function and procedure bodies without being passed as explicit parameters. Subscript ranges are not accessible in D or Rust. I do not understand the meaning of "subscript ranges"? Isn't this slicing? I believe this means the range of the underlying array. For arrays on the heap, the D runtime could actually figure this out (using the same mechanism as for calculating .capacity), but of course it can't be done generally.
Re: Generically call a function on Variant's payload?
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?
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: ./install.sh dmd broken?
On Monday, 13 August 2018 at 17:10:13 UTC, Jonathan Marler wrote: The problem is downloading "install.sh" directly to "~/dlang/install.sh". This causes the install script to think that it has already downloaded the "d-keyring.gpg" so it never downloads it, causing the "invalid signature" error. The fix is to download "install.sh" if the d-keyring is not downloaded, even if install.sh already is. Spot on! Thanks...
Re: Auto keyword and when to use it
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
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
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.
[Issue 18609] `is` expression identifier accessible outside `static if`
https://issues.dlang.org/show_bug.cgi?id=18609 ZombineDev changed: What|Removed |Added CC||petar.p.ki...@gmail.com --- Comment #1 from ZombineDev --- `static if` doesn't create a scope, so I think the current behavior is correct, though a bit suprising. --
Re: Friends don't let friends use inout with scope and -dip1000
On Tuesday, 21 August 2018 at 13:42:31 UTC, Kagamin wrote:
int[] escape(scope int[] r)
{
return r; //error, can't return scoped argument
}
...
int[] escape(T)(scope int[] r)
{
return r; //ok! `scope` silently promoted to `return`
}
You can't have strictly scoped parameter in a templated
function - it's silently promoted to return parameter. Is this
intended?
I filed a similar bug (it uses return type inference rather than
a template). Walter closed it as invalid:
https://issues.dlang.org/show_bug.cgi?id=17362
Re: Auto keyword and when to use it
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.
[Issue 18609] `is` expression identifier accessible outside `static if`
https://issues.dlang.org/show_bug.cgi?id=18609 Nick Treleaven changed: What|Removed |Added Keywords||accepts-invalid Severity|enhancement |normal --
Re: Dub and it's build directory
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: LDC 1.11.0
On Sunday, 19 August 2018 at 10:11:42 UTC, 鲜卑拓跋枫 wrote: Many thanks for your effort! And hope the subsequent LDC releases with LLVM 7.0 will be mature enough on AArch64 and RISC-V for production environment. Who is actually running AArch64 or RISC-V in a "production environment?" Maybe a few for AArch64, but pretty much nobody for RISC-V. I tried looking for a RISC-V VPS or dev board recently and found basically nothing, just two boards from SiFive that are too small or too expensive.
wiki.dlang.org confirmation emails marked as spam by gmail
gmail gives the reason: "Lots of messages from k3.1azy.net were identified as spam in the past." Not sure what can be done. Just an FYI.
Re: Beta 2.082.0
On Saturday, 18 August 2018 at 16:51:18 UTC, Martin Nowak wrote: I understand that common Windows users have a very different thread model than linux developers, hence the crappy Anti-Virus rootkits. I'd expect the Windows dev audience we're targeting with D to be a bit more capable than common Windows users though. Since introduction of UAC in Vista viruses became a non-issue and the theme lost buzz, that can foster ignorance.
Re: Auto keyword and when to use it
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
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.
[Issue 19097] Extend Return Scope Semantics
https://issues.dlang.org/show_bug.cgi?id=19097 Atila Neves changed: What|Removed |Added CC||atila.ne...@gmail.com --- Comment #7 from Atila Neves --- @Mike It applies to constructors in the same way it applies to `void` functions whose first argument is `ref` or `out`. The hidden first parameter to the constructor is a `ref` parameter: `this`. I think a better way to describe this issue is that first parameters that are `ref` or `out` (including `this` for constructors) should be considered and treated the same as return values for other functions. --
Re: Engine of forum
On 8/21/18 10:08 AM, Ali wrote: On Tuesday, 21 August 2018 at 05:30:07 UTC, Walter Bright wrote: Ask 10 people, and you'll get 10 different answers on what a better forum would be. Actually I think we can get 8 out of those 10 to agree, rust, ocaml, fsharp, nim, scala, clojure .. all use https://www.discourse.org/ I think this software is nowadays regarded and the best Cool! Does it support an interface on top of a newsgroup server? Priority #1 in these parts. If people leave because of the forum software, changing it won't change that. I also agree with that, most people who leave probably leave for more objective reasons, like that the language doesn't answer their needs, or they didnt find the libraries they needed within the ecosystem etc... But what I really meant, is that out of those who leaves, there is possible a very small percentage who left, because they couldnt communicate effectively with the community, and that better communication channels in general ( and a better forum software as an example) could have kept them around for longer , replacing the forum software is a small change, a small win, and I expect small returns. But a small win, is a win On the contrary, many of the regular contributors here, don't give a lick about the forum software, as long as it's primarily backed by the newsgroup server. Many, including myself use the NG server, many others use the mailing list interface. If the NG was ditched, I would have a big problem communicating, as I hate dealing with web forums. The forum software probably could be better in terms of formatting code (see for example vibe.d's forums which are ALSO NG backed and have code formatting features). Other than that, editing posts just doesn't make sense in terms of a mailing list or newsgroup. And it also doesn't make sense in terms of a discussion where things you thought you read mysteriously change. -Steve
Re: Is @safe still a work-in-progress?
On Tuesday, 21 August 2018 at 00:09:03 UTC, Walter Bright wrote: On 8/20/2018 6:46 AM, Steven Schveighoffer wrote: I would, but I have no idea how dip1000 is supposed to work. I think only you understand it. Even looking at the PR that you have been citing over and over, I can't make heads or tails of what it does or what it allows. The way to understand dip1000 is to forget about `this`, arrays, structs, classes, delegates, etc. Just think about pointers - functions that take pointers as arguments, and return pointers. That simplifies things enormously. Once that makes sense, then deconstruct the higher level constructs into pointers, and then you'll see how they work. This is why my presentation does it all in terms of pointers: http://dconf.org/2017/talks/bright.html If you're having trouble understanding a particular example, rewrite it in terms of pointers. If it still is inscrutable, then ask about the pointer version here. (When someone gives me some complex thing and says "I don't understand scope here", I always first rewrite it in terms of pointers. It's the same thing I do with bug reports that use templates - I manually instantiate the templates first.) The problem is that the code we write doesn't deal directly with pointers - see the recent confusion in this forum over where `scope` on the left applies to the `this` pointer or the one returned by the member function. Kagamin just told me I needed to use `return` instead of `scope` to get things to work and I'm still not sure why. Also: destructors? Always `scope`? Sometimes? I just add `scope` when the compiler complains at this point. I think it's interesting that when I played with Rust I didn't have problems fighting the borrow checker at all. DIP1000 is supposed to have the same safety without the Rust complications but currently Rust is much easier to understand for me. It doesn't help that the current implementation of -dip1000 doesn't match the document it's supposedly based on.
Re: Friends don't let friends use inout with scope and -dip1000
On Tuesday, 21 August 2018 at 11:28:39 UTC, Nicholas Wilson wrote: On Tuesday, 21 August 2018 at 10:57:15 UTC, Atila Neves wrote: On Tuesday, 21 August 2018 at 09:50:46 UTC, Atila Neves wrote: On Monday, 20 August 2018 at 15:55:54 UTC, Kagamin wrote: On Monday, 20 August 2018 at 13:02:23 UTC, Atila Neves wrote: On Monday, 20 August 2018 at 12:56:42 UTC, Kagamin wrote: Error: address of variable s assigned to gInt with longer lifetime Looks safe to me. With dmd 2.081.2 on Arch Linux, the code above compiles with no error message. Never mind, I forgot to use -dip1000. Ok, cool, so _why_ does it work as intended now? Also, if I have to remember to annotate correctly, surely this is a massive hole in @safe dip1000? MyStruct is not a template, I presume `return` would get inferred if it was. But yeah that is annoying. At the very least then it should fail to compile if I don't add the relevant annotation, not silently accept buggy code that isn't memory safe but somehow _is_ `@safe`. That's the whole point of -dip1000, no? If I get around it by forgetting something, it's not going to work.
Re: Engine of forum
On Tuesday, 21 August 2018 at 14:18:40 UTC, Seb wrote: On Tuesday, 21 August 2018 at 03:42:21 UTC, Ali wrote: On Monday, 20 August 2018 at 09:52:01 UTC, Peter Alexander wrote: [...] What are the specific problems solved by using better software? Well, most software projects, have different channels of communications, some use forums, some use newsgroups, some use irc, some use slack, Yep, D also has an active IRC channel (#d) and Slack group (https://forum.dlang.org/post/gidqeijjswgnpveog...@forum.dlang.org). some rely on stackoverflow, some have an active wiki There are a few good points to move D.learn to Stack Overflow and that's actually one thing that we have talked about a few times and somehow never has happened. In the D survey there was a 2:1 "consensus" for StackOverflow. That would increase the visibility of D as well!
Re: Engine of forum
On Tuesday, 21 August 2018 at 14:08:01 UTC, Ali wrote: [...] But what I really meant, is that out of those who leaves, there is possible a very small percentage who left, because they couldnt communicate effectively with the community, Are you serious? This forum software is the most effektive I know. It is also efficient, especially for reading messages. and that better communication channels in general ( and a better forum software as an example) could have kept them around for longer, To what advantage? replacing the forum software is a small change, Arguably... a small win, and I expect small returns. But a small win, is a win It’s not a win in everybody’s minds ;-) I’m not saying that the forum cannot be improved, but to scrap it would be a loss if you ask me.
Re: Cast to original type each argument in template pack
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: Engine of forum
On Tuesday, 21 August 2018 at 03:42:21 UTC, Ali wrote: On Monday, 20 August 2018 at 09:52:01 UTC, Peter Alexander wrote: What are the specific problems solved or opportunities realised by moving to a real forum? What are the specific problems solved by using better software? Well, most software projects, have different channels of communications, some use forums, some use newsgroups, some use irc, some use slack, Yep, D also has an active IRC channel (#d) and Slack group (https://forum.dlang.org/post/gidqeijjswgnpveog...@forum.dlang.org). some rely on stackoverflow, some have an active wiki There are a few good points to move D.learn to Stack Overflow and that's actually one thing that we have talked about a few times and somehow never has happened. In the D survey there was a 2:1 "consensus" for StackOverflow.
Re: Engine of forum
On Tuesday, 21 August 2018 at 05:30:07 UTC, Walter Bright wrote: Ask 10 people, and you'll get 10 different answers on what a better forum would be. Actually I think we can get 8 out of those 10 to agree, rust, ocaml, fsharp, nim, scala, clojure .. all use https://www.discourse.org/ I think this software is nowadays regarded and the best If people leave because of the forum software, changing it won't change that. I also agree with that, most people who leave probably leave for more objective reasons, like that the language doesn't answer their needs, or they didnt find the libraries they needed within the ecosystem etc... But what I really meant, is that out of those who leaves, there is possible a very small percentage who left, because they couldnt communicate effectively with the community, and that better communication channels in general ( and a better forum software as an example) could have kept them around for longer , replacing the forum software is a small change, a small win, and I expect small returns. But a small win, is a win
Re: Friends don't let friends use inout with scope and -dip1000
On 8/21/18 9:42 AM, Kagamin wrote:
except for templated functions:
int[] escape(scope int[] r)
{
return r; //error, can't return scoped argument
}
int[] escape(return int[] r)
{
return r; //ok, just as planned
}
int[] escape(return scope int[] r)
{
return r; //ok, `return scope` reduced to just `return`
}
int[] escape(T)(scope int[] r)
{
return r; //ok! `scope` silently promoted to `return`
}
You can't have strictly scoped parameter in a templated function - it's
silently promoted to return parameter. Is this intended?
I would guess it's no different than other inferred attributes. I would
also guess that it only gets promoted to a return parameter if it's
actually returned.
As long as the *result* is scoped like the parameter. In the case of the
OP in this thread, there is definitely a problem with inout and the
connection to the return value.
-Steve
Re: Friends don't let friends use inout with scope and -dip1000
...except for templated functions:
int[] escape(scope int[] r)
{
return r; //error, can't return scoped argument
}
int[] escape(return int[] r)
{
return r; //ok, just as planned
}
int[] escape(return scope int[] r)
{
return r; //ok, `return scope` reduced to just `return`
}
int[] escape(T)(scope int[] r)
{
return r; //ok! `scope` silently promoted to `return`
}
You can't have strictly scoped parameter in a templated function
- it's silently promoted to return parameter. Is this intended?
[Issue 19175] @safe code can escape local array references
https://issues.dlang.org/show_bug.cgi?id=19175
--- Comment #4 from anonymous4 ---
@safe:
struct A(T)
{
int[] r;
this(int[] q){r=q;}
}
int[] escape(T)(int[] r)
{
return A!int(r).r;
}
int[] f()
{
int[6] xs = [0, 1, 2, 3, 4, 5];
return xs.escape!int;
}
--
[Issue 19175] @safe code can escape local array references
https://issues.dlang.org/show_bug.cgi?id=19175
--- Comment #3 from anonymous4 ---
Reduced:
@safe:
struct A(alias fun)
{
int[] r;
this(int[] q){r=q;}
}
template m(alias fun)
{
auto m(int[] r)
{
return A!fun(r);
}
}
auto foo() {
int[6] xs = [0, 1, 2, 3, 4, 5];
return xs[].m!(x => x);
}
void main() {
auto a=foo();
}
--
Re: Dub and it's build directory
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?
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?
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: Friends don't let friends use inout with scope and -dip1000
I mean if one method in structure is trusted, other methods need manual verification too.
Re: Friends don't let friends use inout with scope and -dip1000
On Tuesday, 21 August 2018 at 10:57:15 UTC, Atila Neves wrote: Also, if I have to remember to annotate correctly, surely this is a massive hole in @safe dip1000? In general, safety works per method and doesn't help much in building safe data structures, those are trusted as a whole. EMSI containers are a notable big victim of this thing.
Re: Friends don't let friends use inout with scope and -dip1000
On Tuesday, 21 August 2018 at 10:57:15 UTC, Atila Neves wrote:
Never mind, I forgot to use -dip1000. Ok, cool, so _why_ does
it work as intended now? Also, if I have to remember to
annotate correctly, surely this is a massive hole in @safe
dip1000?
It thought dip1000 was impenetrable, but if I understand it
(honestly that's a surprise!), `scope` has strict semantics: all
in, nothing out; you don't need to think about lifetime of data
passed to scope parameters, because it doesn't escape anywhere.
If you want to return data extracted from argument, `return`
attribute relaxes scoping rules and allows to return data and
passes scoping properties from argument to return value much like
`inout` does for const.
Without annotation:
@safe:
struct MyStruct
{
import core.stdc.stdlib;
int* ints;
this(int size) @trusted { ints = cast(int*) malloc(size); }
~this() scope @trusted { free(ints); }
inout(int)* ptr() inout { return ints; }
}
int* gInt;
void f()
{
scope s=MyStruct(10);
gInt=s.ptr;
}
Error: scope variable s assigned to non-scope parameter this
calling MyStruct.ptr
Doesn't let to call method without annotation.
Re: Friends don't let friends use inout with scope and -dip1000
On Tuesday, 21 August 2018 at 10:57:15 UTC, Atila Neves wrote: On Tuesday, 21 August 2018 at 09:50:46 UTC, Atila Neves wrote: On Monday, 20 August 2018 at 15:55:54 UTC, Kagamin wrote: On Monday, 20 August 2018 at 13:02:23 UTC, Atila Neves wrote: On Monday, 20 August 2018 at 12:56:42 UTC, Kagamin wrote: Error: address of variable s assigned to gInt with longer lifetime Looks safe to me. With dmd 2.081.2 on Arch Linux, the code above compiles with no error message. Never mind, I forgot to use -dip1000. Ok, cool, so _why_ does it work as intended now? Also, if I have to remember to annotate correctly, surely this is a massive hole in @safe dip1000? MyStruct is not a template, I presume `return` would get inferred if it was. But yeah that is annoying.
[Issue 18051] missing enum support in formattedRead/unformatValue
https://issues.dlang.org/show_bug.cgi?id=18051 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/6a0a91a8135cc0ce10253c23e788b0782bce165e Use version(TestComplex) as a workaround against issue 18051 --
[Issue 19162] [REG: 2.079.0] Public Import Overlapping Names Conflict Resolution
https://issues.dlang.org/show_bug.cgi?id=19162 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/1798119abff6b7226ad65ce57339a26f0ab0bf4e Fix issue 19162 https://github.com/dlang/phobos/commit/dc2c899e16a8e15b55ce63c3b260efc6a5cb1eaf Merge pull request #6664 from look-at-me/master Fix issue 19162 - [REG: 2.079.0] Public Import Overlapping Names Conflict Resolution merged-on-behalf-of: Petar Kirov --
[Issue 19162] [REG: 2.079.0] Public Import Overlapping Names Conflict Resolution
https://issues.dlang.org/show_bug.cgi?id=19162 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: Friends don't let friends use inout with scope and -dip1000
On Tuesday, 21 August 2018 at 09:50:46 UTC, Atila Neves wrote:
On Monday, 20 August 2018 at 15:55:54 UTC, Kagamin wrote:
On Monday, 20 August 2018 at 13:02:23 UTC, Atila Neves wrote:
On Monday, 20 August 2018 at 12:56:42 UTC, Kagamin wrote:
[...]
I need `return` for what exactly? Your code still compiles,
and my point is it shouldn't. It sure isn't memory safe.
@safe:
struct MyStruct
{
import core.stdc.stdlib;
int* ints;
this(int size) @trusted { ints = cast(int*) malloc(size); }
~this() @trusted { free(ints); }
inout(int)* ptr() return inout { return ints; }
}
int* gInt;
void f()
{
auto s=MyStruct(10);
gInt=s.ptr;
}
Error: address of variable s assigned to gInt with longer
lifetime
Looks safe to me.
With dmd 2.081.2 on Arch Linux, the code above compiles with no
error message.
Never mind, I forgot to use -dip1000. Ok, cool, so _why_ does it
work as intended now? Also, if I have to remember to annotate
correctly, surely this is a massive hole in @safe dip1000?
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #4 from Atila Neves ---
I made a mistake when I posted the code. This compiles but shouldn't (the only
difference is removing `scope` from the destructor).
I also surrounded the call to `free` with @trusted instead of the whole
constructor.
@safe:
const(int)* gInts;
void main() {
auto s = MyStruct(10);
gInts = s.ints;
}
struct MyStruct
{
import core.stdc.stdlib;
int* ints;
this(int size) @trusted { ints = cast(int*) malloc(size); }
~this() { () @trusted { free(ints); }(); }
scope ptr(this This)() { return ints; }
}
--
Re: Beta 2.082.0
On Friday, 17 August 2018 at 20:01:32 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.082.0 release, ♥ to the 47 contributors for this release. [...] Could I pretty please get this absolutely non-controversial regression fix in before the release? https://github.com/dlang/dmd/pull/8542
Re: D need an ORM library!
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.
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183 ZombineDev changed: What|Removed |Added CC||petar.p.ki...@gmail.com --- Comment #3 from ZombineDev --- It seems that you're not passing -dip1000 on the command-line. I'm also on Arch Linux. Here's what I get: ~/dlang/install.sh dmd source ~/dlang/dmd-2.081.2/activate dmd -dip1000 scope.d scope.d(7): Error: scope variable s assigned to gInts with longer lifetime --
Re: Friends don't let friends use inout with scope and -dip1000
On Monday, 20 August 2018 at 15:55:54 UTC, Kagamin wrote:
On Monday, 20 August 2018 at 13:02:23 UTC, Atila Neves wrote:
On Monday, 20 August 2018 at 12:56:42 UTC, Kagamin wrote:
[...]
I need `return` for what exactly? Your code still compiles,
and my point is it shouldn't. It sure isn't memory safe.
@safe:
struct MyStruct
{
import core.stdc.stdlib;
int* ints;
this(int size) @trusted { ints = cast(int*) malloc(size); }
~this() @trusted { free(ints); }
inout(int)* ptr() return inout { return ints; }
}
int* gInt;
void f()
{
auto s=MyStruct(10);
gInt=s.ptr;
}
Error: address of variable s assigned to gInt with longer
lifetime
Looks safe to me.
With dmd 2.081.2 on Arch Linux, the code above compiles with no
error message.
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183 --- Comment #2 from Atila Neves --- I used dmd 2.081.2. I just tried it again and it compiles. Just in case there's something wrong with the Arch Linux package, I used dmd.081.2 from install.sh. Same result. I also tried the 2.082.0 beta 1. Same thing. --
[Issue 19175] @safe code can escape local array references
https://issues.dlang.org/show_bug.cgi?id=19175 Seb changed: What|Removed |Added CC||greensunn...@gmail.com --
Re: Found on proggit: Why D is a good choice for writing a language
On Tuesday, 21 August 2018 at 08:21:41 UTC, tiensonqin wrote: now it's fixed, Thank you!
Re: Deduce type of struct in function arguments
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
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: Found on proggit: Why D is a good choice for writing a language
On Friday, 17 August 2018 at 11:29:46 UTC, zabruk wrote: https://lambdahackers.com/@b4asile/why-d-is-a-good-choice-for-writing-a-toy-language-4vapyvas5a Can anyone explain me the purpose of javascript on this page? Especialy various mouse click event handlers, those break common well-known handfull browser behaviour? I can't select text and press mouse r-click to invoke firefox gtranslate plugin for selected text for example. Hi zabruk, sorry for the bug. I have to listen on `on-mouse-down` to let users to quote comment, now it's fixed, https://github.com/tiensonqin/lambdahackers/issues/46
Re: D need an ORM library!
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
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?
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: Engine of forum
On Tuesday, 21 August 2018 at 03:42:21 UTC, Ali wrote: Many of those new comers who ask about the forum software .. they never stick, they dont complain, or question, or try to change for the better, they simply leave I think this is the best forum I have ever used, it's a big contributing factor to that I post here! I don't post every month praising the forum, I'm silently happy. But if we changed I would likely complain every month.
Re: Deduce type of struct in function arguments
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?
[Issue 18545] Casting away const with cast() triggers alias this, but returns the supertype anyway
https://issues.dlang.org/show_bug.cgi?id=18545 --- Comment #1 from FeepingCreature --- It turns out what's happening here is that cast() constNullable is equivalent to Nullable(constNullable)... which implicitly casts to constNullable.get. alias get this strikes again! Nullable should maybe have a copy constructor from const? --
Re: Generically call a function on Variant's payload?
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 ;)
