Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Wednesday, April 11, 2018 05:23:58 really? via Digitalmars-d-announce
wrote:
> On Friday, 6 April 2018 at 17:36:20 UTC, H. S. Teoh wrote:
> > Yeah, I think having expression syntax will make contracts more
> > readable. We'll just have to see.
>
> Sorry, but I fail to see how (1) is more readable than (2)
>
> (1)
> in(s.length > 0, "s must not be empty")
>
> (2)
> in { assert(s.length > 0, "s must not be empty"); }
>
>
> In (1) The assert .. is removed.
> In (1) The scope indicators {} .. are removed.
> In (1) The semicolon..is removed.
>
> Removing all these things equates to being more readable??
>
> Sure, it makes it more concise, but more readable??
>
> I assert that it does not. But now..do I use the assert keyword..
> or not? Do I end with semicolon..or not??
>
> This just removes things that are still needed elsewhere in your
> code, but now... you have to remember that sometimes you need
> those things, and sometimes you don't.
>
> Better to have consistency over conciseness
>
> so glad to hear that existing syntax will remain.
> (well, till someone decides that needs to go too)
Many have considered the verboseness of contracts to be a major reason to
avoid them. The newer syntax will help with that in the cases where all you
need is a series of assertions. However, regardless of how anyone feels
about the new syntax, there are cases where you need more than just a series
of assertions (e.g. you need to declare one or more variables to use in the
assertions). The older syntax is required for such cases, and it would make
no sense to remove it even if we didn't care about avoiding code breakage.
So, if you prefer the older syntax, then feel free to use it, even if the
newer syntax will work. You'll be stuck reading the newer syntax in the code
of anyone who prefers the newer syntax, so you can't necessarily avoid
dealing with it, but you're not going to be forced to switch to the newer
syntax if you don't want to.
Personally, I think that new syntax is very straightforward. It may take
some getting used to, but it's basically the same syntax as an assertion
except that it has a different keyword, and because it's not a statement, it
doesn't need a semicolon. It makes sense in its context, and ultimately, I
don't think that it's really going to be readability problem.
That being said, I'm probably still not going to bother with contracts
simply because I don't see any real benefit over just putting assertions
inside the function except in the cases where inheritance is involved. I
find it a lot more tolerable than the old syntax, but I still find it to be
pointless so long as contracts are the same thing as putting assertions
inside the function (except when inheritance is involved). IMHO, for
contracts to be worth much outside of the inheritance case, we'd need to do
something like make it so that contracts are compiled in based on whether
the caller used -release or not rather than whether the callee did. If that
were done, then there would be real value in using contracts, and I'd be a
lot more excited about the new syntax. As it is, it seems like a nice
improvement that's ultimately pointless.
- Jonathan M Davis
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Friday, 6 April 2018 at 17:36:20 UTC, H. S. Teoh wrote:
Yeah, I think having expression syntax will make contracts more
readable. We'll just have to see.
Sorry, but I fail to see how (1) is more readable than (2)
(1)
in(s.length > 0, "s must not be empty")
(2)
in { assert(s.length > 0, "s must not be empty"); }
In (1) The assert .. is removed.
In (1) The scope indicators {} .. are removed.
In (1) The semicolon..is removed.
Removing all these things equates to being more readable??
Sure, it makes it more concise, but more readable??
I assert that it does not. But now..do I use the assert keyword..
or not? Do I end with semicolon..or not??
This just removes things that are still needed elsewhere in your
code, but now... you have to remember that sometimes you need
those things, and sometimes you don't.
Better to have consistency over conciseness
so glad to hear that existing syntax will remain.
(well, till someone decides that needs to go too)
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 20:32:05 UTC, Seb wrote: On Tuesday, 10 April 2018 at 16:51:57 UTC, Atila Neves wrote: If you get to the point where you can #include , it will be doubly impressive! Not *if*, *when*. ;) Atila FYI people have been fighting with this for a long time: https://github.com/dlang/druntime/pull/1316 The beauty of using libclang is that name mangling issues don't exist. :) It's still not going to be easy, but that's one worry I won't have to bother with. Atila
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 20:32:05 UTC, Seb wrote: On Tuesday, 10 April 2018 at 16:51:57 UTC, Atila Neves wrote: If you get to the point where you can #include , it will be doubly impressive! Not *if*, *when*. ;) Atila FYI people have been fighting with this for a long time: https://github.com/dlang/druntime/pull/1316 FYI this appears to work just fine in Calypso: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/libstdc%2B%2B/vector.d — David
Re: code-d 0.17.0 + serve-d 0.1.2
On Tuesday, 10 April 2018 at 03:37:59 UTC, evilrat wrote: On Monday, 9 April 2018 at 19:10:46 UTC, Samson wrote: [...] Disable "normal" code-d, close VS, remove %appdata%/code-d, launch VS & enable code-d beta serve-d, enjoy. [...] Thanks, your suggestion work for me. Many thanks to you
Re: code-d 0.17.0 + serve-d 0.1.2
On Tuesday, 10 April 2018 at 03:37:59 UTC, evilrat wrote: On Monday, 9 April 2018 at 19:10:46 UTC, Samson wrote: [...] Disable "normal" code-d, close VS, remove %appdata%/code-d, launch VS & enable code-d beta serve-d, enjoy. [...] Thanks your suggestion work for me. many thanks to you
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 16:51:57 UTC, Atila Neves wrote: If you get to the point where you can #include , it will be doubly impressive! Not *if*, *when*. ;) Atila FYI people have been fighting with this for a long time: https://github.com/dlang/druntime/pull/1316
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 19:28:09 UTC, Steven Schveighoffer wrote: On 4/10/18 2:36 PM, Atila Neves wrote: Haha, I remember. I do plan on dealing with emplace_back, but I have no idea how just yet and I was hoping nobody was going to call me on it until then. Busted! :P I think we all agree you aren't going to instantiate C++ templates in D (and who would want to). Do we? Do I? :P (I've actually seriously considered it) But since you are using a wrapper to call the compiler, and invoking clang anyway, generating a file to compile which calls the template to generate the object file for the method, and then using the symbol generated to bind to the method might be possible. Of course, you first have to compile your D code to see what templates to generate! So this is another extra step. That's one of my ideas. It could be as easy as generating a mock C++ template for vector, that then has a symbol that d++ recognizes and both replaces with a real call AND helps you figure out what C++ template to generate. -vcg-ast may help here. The details elude me right now, but that seems to make sense. Whatever this is going to be, it ain't going to be fast... Compiling C++ isn't known to be fast. ;) It might be possible to limit the damage by confining the C++ #includes to one D package or module so it doesn't get rebuilt every time. Atila
Re: #include C headers in D code
On 4/10/18 2:36 PM, Atila Neves wrote: Haha, I remember. I do plan on dealing with emplace_back, but I have no idea how just yet and I was hoping nobody was going to call me on it until then. Busted! :P I think we all agree you aren't going to instantiate C++ templates in D (and who would want to). But since you are using a wrapper to call the compiler, and invoking clang anyway, generating a file to compile which calls the template to generate the object file for the method, and then using the symbol generated to bind to the method might be possible. Of course, you first have to compile your D code to see what templates to generate! So this is another extra step. It could be as easy as generating a mock C++ template for vector, that then has a symbol that d++ recognizes and both replaces with a real call AND helps you figure out what C++ template to generate. -vcg-ast may help here. Whatever this is going to be, it ain't going to be fast... -Steve
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 18:01:37 UTC, Steven Schveighoffer wrote: On 4/10/18 12:51 PM, Atila Neves wrote: On Tuesday, 10 April 2018 at 13:53:34 UTC, Steven Schveighoffer wrote: If you get to the point where you can #include , it will be doubly impressive! Not *if*, *when*. ;) I hope you are right, but I remain skeptical :) If I may throw a curveball back at you, I recall a question at last year's dconf during the talk about interfacing with C++ STL about using emplace_back instead of push_back. And the questioner who happened to be sitting next to me said "meh, push_back isn't very useful, nobody uses push_back any more" :P -Steve Haha, I remember. I do plan on dealing with emplace_back, but I have no idea how just yet and I was hoping nobody was going to call me on it until then. Busted! :P Atila
Re: #include C headers in D code
On 4/10/18 12:51 PM, Atila Neves wrote: On Tuesday, 10 April 2018 at 13:53:34 UTC, Steven Schveighoffer wrote: If you get to the point where you can #include , it will be doubly impressive! Not *if*, *when*. ;) I hope you are right, but I remain skeptical :) If I may throw a curveball back at you, I recall a question at last year's dconf during the talk about interfacing with C++ STL about using emplace_back instead of push_back. And the questioner who happened to be sitting next to me said "meh, push_back isn't very useful, nobody uses push_back any more" :P -Steve
Re: code-d 0.17.0 + serve-d 0.1.2
Am 10.04.2018 um 14:27 schrieb WebFreak001: > On Monday, 9 April 2018 at 21:45:57 UTC, Johannes Loher wrote: >> Am 04.04.2018 um 20:34 schrieb greatsam4sure: >>> [...] >> I just tried to get this to work, too, but I was not able to get it to >> work correctly. It seems that running dub fails somehow: >> >> [...] > > hm before it would have completely crashed workspace-d/serve-d to a > point where nothing would work, now you basically only get stdlib and a > guess of further import paths. Can you make a minimal test case where > this happens? It is probably due to some dub.json settings. But as I use > dub as a library it should work the same as just calling `dub build` You are right, it indeed seems to be a dub problem. Running `dub build` gives me "Could not resolv configuration for package vibe-d". The strange thing is, it workls correctly on Linux / OS X with the same dub/dmd versions... I tried it with another project with a more simple dub.json and it works fine out of the box. Very nice job!
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 13:53:34 UTC, Steven Schveighoffer wrote: On 4/9/18 7:03 AM, Atila Neves wrote: [...] Awesome. Can't say I will use it, as I don't use C much, but I understand how difficult a task this is. Thanks! If you get to the point where you can #include , it will be doubly impressive! Not *if*, *when*. ;) Atila
Re: Homebrew dmd betas
On 4/10/18 1:46 AM, John Colvin wrote: On Saturday, 7 April 2018 at 18:39:12 UTC, Martin Nowak wrote: First beta for the 2.079.1 patch release. Comes with a handful of fixes. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.079.1.html Please report any bugs at https://issues.dlang.org - -Martin Available now on homebrew :) [snip] I haven't tried the betas yet, but many thanks for keeping homebrew up to date with the regular releases!
Re: code-d 0.17.0 + serve-d 0.1.2
On Tuesday, 10 April 2018 at 13:11:16 UTC, evilrat wrote: On Tuesday, 10 April 2018 at 11:54:47 UTC, WebFreak001 wrote: fyi "deprecated" code-d beta and normal code-d is exactly the same plugin right now using exactly the same serve-d versions, except for the deprecation message. I wouldn't be complaining if it's not the case. With normal code-d it does remove everything in %appdata%/code-d on start, re-setting config paths(even though for exapmle dub is in PATH), downloading git repo, fails to build, and repeat, while with beta there is no such issues. I would also suggest you to add explicit --compiler=dmd switch to build invocation since for example in my case dmd was in PATH env after ldc and so ldc used by default, which of course doesn't have x86_mscoff arch. I also think it is probably better to add --build=release too, since users usually don't do debug on that binaries. No dmd has an optimization issue that it removes code making the program completely broken and freeze on IO if compiled with -O, which is implied by --build=release. I will never use build=release with dmd. What about workspaces? Let for exapmle have main project (really just a dub project with single app.d for testing library) and library project in one workspace. I don't get any autocompletion from both projects. It also doesn't seems to work with dependency that has path property set, at least not when it's relative. Is this ok? Everything dub dependency related should work, I literally use dub as a library for this. Multi workspaces in vscode aren't implemented yet though.
Re: #include C headers in D code
On 4/9/18 7:03 AM, Atila Neves wrote:
Here's my blog post about my project that allows directly #including C
headers in D*
https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/
The summary is that, modulo bugs, things like this work:
#include
void main() { printf("Hello world\n".ptr); }
So far it's successfully compiled whilst #including pthread, libcurl,
openssl and others. The blog and the github README have more
information, and feel free to reply to this with questions.
dub: http://code.dlang.org/packages/dpp
reddit:
https://www.reddit.com/r/programming/comments/8axj53/include_c_headers_in_d_code/
hacker news: It's in there somewhere, search around.
Atila
* Technically, "D + #include directives + C macros"
Awesome. Can't say I will use it, as I don't use C much, but I
understand how difficult a task this is.
If you get to the point where you can #include , it will be
doubly impressive!
-Steve
Re: code-d 0.17.0 + serve-d 0.1.2
On Tuesday, 10 April 2018 at 11:54:47 UTC, WebFreak001 wrote: fyi "deprecated" code-d beta and normal code-d is exactly the same plugin right now using exactly the same serve-d versions, except for the deprecation message. I wouldn't be complaining if it's not the case. With normal code-d it does remove everything in %appdata%/code-d on start, re-setting config paths(even though for exapmle dub is in PATH), downloading git repo, fails to build, and repeat, while with beta there is no such issues. I would also suggest you to add explicit --compiler=dmd switch to build invocation since for example in my case dmd was in PATH env after ldc and so ldc used by default, which of course doesn't have x86_mscoff arch. I also think it is probably better to add --build=release too, since users usually don't do debug on that binaries. What about workspaces? Let for exapmle have main project (really just a dub project with single app.d for testing library) and library project in one workspace. I don't get any autocompletion from both projects. It also doesn't seems to work with dependency that has path property set, at least not when it's relative. Is this ok?
Re: code-d 0.17.0 + serve-d 0.1.2
On Monday, 9 April 2018 at 21:45:57 UTC, Johannes Loher wrote: Am 04.04.2018 um 20:34 schrieb greatsam4sure: [...] I just tried to get this to work, too, but I was not able to get it to work correctly. It seems that running dub fails somehow: [...] hm before it would have completely crashed workspace-d/serve-d to a point where nothing would work, now you basically only get stdlib and a guess of further import paths. Can you make a minimal test case where this happens? It is probably due to some dub.json settings. But as I use dub as a library it should work the same as just calling `dub build`
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 09:36:39 UTC, Atila Neves wrote: On Monday, 9 April 2018 at 20:19:35 UTC, Seb wrote: On Monday, 9 April 2018 at 19:36:23 UTC, Atila Neves wrote: On Monday, 9 April 2018 at 18:15:33 UTC, kinke wrote: [...] This whole idea came about because a couple of years ago I was in a team that was responsible for legacy code written in C which had no tests. To write tests, we needed both to write the tests themselves and some fakes/mocks/doubles for the code that we depended on - essentially a whole operating system. I wasn't going to write that in C, since life is too short for that. [...] Speaking of dstep - it has greatly improved over the last years. I'm interested what stop you from using it or improving it (instead of rolling your own tool)? I tried using dstep as the translation engine to avoid reinventing the wheel. I'm lazy, I don't want to write code that doesn't neeed to be written! Nice work. I prefer the DStep approach of translating the headers to D, but obviously it's not going to be as easy for the user as this, so this approach has its uses too. Regarding "reinventing the wheel," I liked this recent blog post giving reasons why it can be a viable approach: https://blog.cerebralab.com/#!/blog/11
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 08:45:06 UTC, Walter Bright wrote: On 4/9/2018 4:03 AM, Atila Neves wrote: Here's my blog post about my project that allows directly #including C headers in D* Very nice work, and great article! Thanks!
Re: #include C headers in D code
On 4/9/2018 4:03 AM, Atila Neves wrote: Here's my blog post about my project that allows directly #including C headers in D* Very nice work, and great article!
Re: #include C headers in D code
On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote: Here's my blog post about my project that allows directly #including C headers in D* neat!
