www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Vision document for H1 2017

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
We release a brief Vision document summarizing the main goals we plan to 
pursue in the coming six months. This half we are focusing on three 
things: safety, lifetime management, and static introspection.

https://wiki.dlang.org/Vision/2017H1


Andrei
Jan 04 2017
next sibling parent Joakim <dlang joakim.fea.st> writes:
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:

 We release a brief Vision document summarizing the main goals 
 we plan to pursue in the coming six months. This half we are 
 focusing on three things: safety, lifetime management, and 
 static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


Nice, a list of concrete tasks, well done.

Only one criticism, some are too short: took me a bit to 
understand what "High-level shared library wrapper" meant, a 
better way to create and deal with shared libraries?  If so, only 
reason I got that is because of your recent forum posts asking 
about loading shared libraries.  Not sure what you want 
overhauled about the dub registry either, might want to expand on 
those, so someone interested could pick up on them.
Jan 04 2017
prev sibling next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:

 We release a brief Vision document summarizing the main goals 
 we plan to pursue in the coming six months. This half we are 
 focusing on three things: safety, lifetime management, and 
 static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


I claim dips on templates. (as in the colloquial english for 
asserting rights/ownership )
I can't wait to improve that situation.
Jan 04 2017
parent reply "H. S. Teoh via Digitalmars-d-announce" writes:
On Wed, Jan 04, 2017 at 08:45:09PM +0000, Stefan Koch via
Digitalmars-d-announce wrote:
[...]

 I claim dips on templates. (as in the colloquial english for asserting
 rights/ownership )


[...]

FYI, it's spelt "dibs" (with a 'b'). ;-)


T

-- 
It won't be covered in the book. The source code has to be useful for
something, after all. -- Larry Wall
Jan 04 2017
parent Random D user <no email.com> writes:
On Wednesday, 4 January 2017 at 21:07:00 UTC, H. S. Teoh wrote:

 On Wed, Jan 04, 2017 at 08:45:09PM +0000, Stefan Koch via 
 Digitalmars-d-announce wrote: [...]

 I claim dips on templates. (as in the colloquial english for 
 asserting
 rights/ownership )


 [...]

 FYI, it's spelt "dibs" (with a 'b'). ;-)


 T


Actually, I think it's spelt "DIPs" (with capitalization) in 
dland ;)

-- Just a random thought
Jan 05 2017
prev sibling next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:

 We release a brief Vision document summarizing the main goals 
 we plan to pursue in the coming six months. This half we are 
 focusing on three things: safety, lifetime management, and 
 static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


I like the social media part. More people, more man power, more 
noise about D.
Jan 04 2017
parent Arun Chandrasekaran <aruncxy gmail.com> writes:
On Wednesday, 4 January 2017 at 21:21:17 UTC, aberba wrote:

 I like the social media part. More people, more man power, more 
 noise about D.


I would read it as, with better signal-to-noise ratio.
Jan 04 2017
prev sibling next sibling parent reply Paul O'Neil <redballoon36 gmail.com> writes:
On 01/04/2017 02:22 PM, Andrei Alexandrescu wrote:

 We release a brief Vision document summarizing the main goals we plan to
 pursue in the coming six months. This half we are focusing on three
 things: safety, lifetime management, and static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


What are the plans for the dub registry?  Have there been discussions 
already?
Jan 04 2017
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 05.01.2017 um 01:59 schrieb Paul O'Neil:

 On 01/04/2017 02:22 PM, Andrei Alexandrescu wrote:

 We release a brief Vision document summarizing the main goals we plan to
 pursue in the coming six months. This half we are focusing on three
 things: safety, lifetime management, and static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


 What are the plans for the dub registry?  Have there been discussions
 already?


I'm not aware of concrete discussions w.r.t. the vision document, but 
the two major improvements that come to mind are GitHub authentication, 
which enables push notifications for repository changes, and some form 
of pagination for the package list views.

Also, one thing we discussed at the last DConf is a "popularity" score 
that would be used for sorting results. This would include things like 
download numbers and GitHub stars. It would also take into account the 
dependencies (which affects the download numbers), so that the score 
actually reflects the perceived popularity as close as possible.

Finally, we want to have a form of CI integration to put packages that 
have tests/pass tests first (i.e. give an incentive for package authors 
to setup and use CI for their project). Generating documentation is 
another possibility, as well as testing DMD frontend version compatibility.
Jan 05 2017
parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 01/05/2017 11:45 PM, Sönke Ludwig wrote:

 Am 05.01.2017 um 01:59 schrieb Paul O'Neil:

 On 01/04/2017 02:22 PM, Andrei Alexandrescu wrote:

 We release a brief Vision document summarizing the main goals we plan to
 pursue in the coming six months. This half we are focusing on three
 things: safety, lifetime management, and static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


 What are the plans for the dub registry?  Have there been discussions
 already?


 
 I'm not aware of concrete discussions w.r.t. the vision document


I think there won't be much discussions about the goals (maybe about the
priorities). Many people come up with the same ideas to resolve the pain
points.

Actually I have a draft for a renewed site, will look at implementing
that (hopefully with Sebastian, Söhnke, and others) in the next few month.

So far haven't found an angle at breaking up the story though, it's
fairly intermingled. If we can't do it incrementally, that would require
a bit more orchestration for a major rerelease.

- better search, also on README bodies (e.g. sqlite FTS)
- tagging instead of hierarchical categories
- ranking (downloads, stars, dependents, testing...)
- better landing page (big search form and listing 10 top, 10 trending,
and 10 newest packages)
- better GH integration

Personally would approach this mid/end of March, but if enough people
have time we could do it earlier.

https://dlang.slack.com/messages/dub/
Jan 07 2017
next sibling parent reply Benjiro <benjiro benjiro.com> writes:
On Saturday, 7 January 2017 at 20:10:17 UTC, Martin Nowak wrote:

 I think there won't be much discussions about the goals (maybe 
 about the priorities). Many people come up with the same ideas 
 to resolve the pain points.

 Actually I have a draft for a renewed site, will look at 
 implementing
 that (hopefully with Sebastian, Söhnke, and others) in the next 
 few month.

 So far haven't found an angle at breaking up the story though, 
 it's fairly intermingled. If we can't do it incrementally, that 
 would require a bit more orchestration for a major rerelease.

 - better search, also on README bodies (e.g. sqlite FTS)
 - tagging instead of hierarchical categories
 - ranking (downloads, stars, dependents, testing...)
 - better landing page (big search form and listing 10 top, 10 
 trending,
 and 10 newest packages)
 - better GH integration


Maybe something to add ( for new users ) is something similar to:

http://rustbyexample.com/

Easy to use, lots of information, simple tasks that involve 
interaction for the user, feedback on success.
Jan 07 2017
parent reply Seb <seb wilzba.ch> writes:
On Saturday, 7 January 2017 at 23:33:45 UTC, Benjiro wrote:

 Maybe something to add ( for new users ) is something similar 
 to:

 http://rustbyexample.com/

 Easy to use, lots of information, simple tasks that involve 
 interaction for the user, feedback on success.


Do you know about the existing Dlang Tour?

https://tour.dlang.org

PRs/Issues to improve it are welcome

Its translation into a couple of languages is WIP:

https://github.com/dlang-tour
Jan 07 2017
parent reply Mark <smarksc gmail.com> writes:
On Sunday, 8 January 2017 at 00:15:23 UTC, Seb wrote:

 On Saturday, 7 January 2017 at 23:33:45 UTC, Benjiro wrote:

 Maybe something to add ( for new users ) is something similar 
 to:

 http://rustbyexample.com/

 Easy to use, lots of information, simple tasks that involve 
 interaction for the user, feedback on success.


 Do you know about the existing Dlang Tour?

 https://tour.dlang.org

 PRs/Issues to improve it are welcome

 Its translation into a couple of languages is WIP:

 https://github.com/dlang-tour


I think the "D for C++ programmers" page could use a revamp:

https://dlang.org/cpptod.html

At the moment it mainly explains where and how D differs from 
C++. Whoever reads it may be ready to write C++ code in D, but 
this seems pointless and may give the impression that D is just 
C++ with a different syntax plus a few minor features (strong 
typedef and the scope statement). The page doesn't mention D's 
dynamic arrays, associative arrays, ranges, UFCS, function 
attributes and so on). The tour does mention these features 
(under "D's gems") so maybe some of its contents can be used to 
extend the "D for C++" page.

One idea on my mind is providing various (honest, not 
specifically tailored) examples of C++ code that aims to solve a 
certain problem, and how the same problem can be solved in D in a 
better way (in some sense). I've seen this done effectively with 
Java vs. Scala.
Jan 12 2017
parent Nick Treleaven <nick geany.org> writes:
On Thursday, 12 January 2017 at 09:54:08 UTC, Mark wrote:

 I think the "D for C++ programmers" page could use a revamp:

 https://dlang.org/cpptod.html

 At the moment it mainly explains where and how D differs from 
 C++. Whoever reads it may be ready to write C++ code in D, but 
 this seems pointless and may give the impression that D is just 
 C++ with a different syntax plus a few minor features (strong 
 typedef and the scope statement). The page doesn't mention D's 
 dynamic arrays, associative arrays, ranges, UFCS, function 
 attributes and so on).


It's intended to help C++ programmers switch to D, not as a 
comparison. It also links to:

https://dlang.org/ctod.html

which does mention arrays and various other small things.

(I noticed some minor things to fix and submitted a pull request).


 One idea on my mind is providing various (honest, not 
 specifically tailored) examples of C++ code that aims to solve 
 a certain problem, and how the same problem can be solved in D 
 in a better way (in some sense). I've seen this done 
 effectively with Java vs. Scala.


Sounds good. I think this thread is for big issues that need core 
focus though, anyone here can and should submit documentation.
Jan 12 2017
prev sibling parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
 - tagging instead of hierarchical categories


The categories are in fact just a form of hierarchical tags. This is 
quite useful, because applying a tag will bring in the ancestor tags for 
free. The UI for both, applying tags and filtering, could be better, 
though. And some form of crowd sourced management of available tags 
could also be interesting to think about.
Jan 09 2017
prev sibling next sibling parent reply Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:

 We release a brief Vision document summarizing the main goals 
 we plan to pursue in the coming six months. This half we are 
 focusing on three things: safety, lifetime management, and 
 static introspection.

 https://wiki.dlang.org/Vision/2017H1


Hi, its interesting to view this in context of previous vision 
documents:

https://wiki.dlang.org/Vision/2015H1
https://wiki.dlang.org/Vision/2015H2
https://wiki.dlang.org/Vision/2016H1
https://wiki.dlang.org/Vision/2016H2

It seems safety and memory management have appeared in all of the 
documents, so presumably the goals haven't been achieved yet. I 
think it would be helpful to have more explicit definition of 
what it would mean for these features to be "done" and is that 
the aim for H1 2017.

C++ integration has disappeared? Is this now "done"?
Jan 04 2017
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/04/2017 08:06 PM, Dibyendu Majumdar wrote:

 C++ integration has disappeared? Is this now "done"?


We have a student on that. I've added a line for that to the doc. -- Andrei
Jan 07 2017
next sibling parent Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Saturday, 7 January 2017 at 15:58:43 UTC, Andrei Alexandrescu 
wrote:

 On 01/04/2017 08:06 PM, Dibyendu Majumdar wrote:

 C++ integration has disappeared? Is this now "done"?


 We have a student on that. I've added a line for that to the 
 doc. -- Andrei


Cool. C++ integration would be a big plus for D so it would be 
great if this feature was completed to a defined standard - by 
this I mean that there ought to be documentation on what works, 
but more importantly, what doesn't, so that users don't have to 
try to work this out by trial and error.

Regards
Dibyendu
Jan 07 2017
prev sibling parent Guillaume Chatelet <chatelet.guillaume gmail.com> writes:
On Saturday, 7 January 2017 at 15:58:43 UTC, Andrei Alexandrescu 
wrote:

 On 01/04/2017 08:06 PM, Dibyendu Majumdar wrote:

 C++ integration has disappeared? Is this now "done"?


 We have a student on that. I've added a line for that to the 
 doc. -- Andrei


I did a lot of work on C++ name mangling for D so feel free to 
introduce me to the student. I can probably save her/him a lot of 
time.

After *many* attempts it seems the only way to get this right is 
to look at how clang does it and replicate the logic (starting 
point 
https://github.com/llvm-mirror/clang/blob/google/stable/include/clang/AST/Mangle.h)

The state of my research on mangling so far are summed up here
https://github.com/gchatelet/gcc_cpp_mangling_documentation

I also have a bunch of failed experiments branches:
- https://github.com/gchatelet/dmd/tree/new_cpp_mangle
- https://github.com/gchatelet/dmd/tree/new_cpp_mangle2
- https://github.com/gchatelet/dmd/tree/new_cpp_mangling2
- https://github.com/gchatelet/dmd/tree/more_mangling_tests

Unfortunately I couldn't spend more time on this :(
Jan 12 2017
prev sibling next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
 Templatize dmd <-> druntime API


I'm curious as to why. I'm guessing this is for things like creating 
runtime type information?
Jan 04 2017
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 5 January 2017 at 02:32:00 UTC, Chris Wright wrote:

 I'm curious as to why. I'm guessing this is for things like 
 creating runtime type information?


There's a lot of benefits to it: it'd simplify the compiler a 
bit, it'd simplify making custom runtimes, and it'd give us 
options to both expand and minimize the runtime info with things 
like compiler switches in druntime.
Jan 04 2017
prev sibling parent Mike <none none.com> writes:
On Thursday, 5 January 2017 at 02:32:00 UTC, Chris Wright wrote:

 Templatize dmd <-> druntime API


 I'm curious as to why. I'm guessing this is for things like 
 creating runtime type information?


This thread 
(http://forum.dlang.org/post/mr7a65$2hc$1 digitalmars.com) should 
provide some context.

Mike
Jan 04 2017
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 05/01/2017 8:22 AM, Andrei Alexandrescu wrote:

 We release a brief Vision document summarizing the main goals we plan to
 pursue in the coming six months. This half we are focusing on three
 things: safety, lifetime management, and static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


The suggestion I want to make related to druntime is, make 
TypeInfo/ModuleInfo actually have (opt-in) full reflection.
This can help decrease template bloat significantly for (de)serializers 
as well as making it so you don't have to explicitly tell your web 
router about all the routes (instead chuck a UDA down and be done with it!).

Andrei: we should talk in a few months about turning my (honors) 
dissertation into research papers. And maybe what I may end up doing for 
masters the following semester.
Jan 04 2017
prev sibling next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:

 We release a brief Vision document summarizing the main goals 
 we plan to pursue in the coming six months. This half we are 
 focusing on three things: safety, lifetime management, and 
 static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


quote from the document:


 Redoing compiler code into lowerings and __traits-based 
 introspection that leverage client code, thus moving compiler 
 smarts into simpler library facilities


To simplify introspection with library traits that use the 
compiler "__traits()" someone has to remove the restrictions 
related to protection attributes. This is not a new topic. 
Without this, the new library traits won't work well and people 
won't use them.
Jan 04 2017
next sibling parent reply Jonathan M Davis via Digitalmars-d-announce writes:
On Thursday, January 05, 2017 04:43:12 Basile B. via Digitalmars-d-announce 
wrote:

 On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu

 wrote:

 We release a brief Vision document summarizing the main goals
 we plan to pursue in the coming six months. This half we are
 focusing on three things: safety, lifetime management, and
 static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


 quote from the document:

 Redoing compiler code into lowerings and __traits-based
 introspection that leverage client code, thus moving compiler
 smarts into simpler library facilities


 To simplify introspection with library traits that use the
 compiler "__traits()" someone has to remove the restrictions
 related to protection attributes. This is not a new topic.
 Without this, the new library traits won't work well and people
 won't use them.


IIRC, it was already agreed that they had to be removed and would be soon,
but we couldn't do it right away either because of code breakage or because
it was a point release that was trying to get out the door. I'm thinking
that it's supposed to be fixed in 2.073, but I'm not 100% sure..

- Jonathan M Davis
Jan 05 2017
parent reply Basile B. <b2.temp gmx.com> writes:
On Thursday, 5 January 2017 at 09:49:16 UTC, Jonathan M Davis 
wrote:

 On Thursday, January 05, 2017 04:43:12 Basile B. via 
 Digitalmars-d-announce wrote:

 On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei 
 Alexandrescu

 wrote:

 We release a brief Vision document summarizing the main 
 goals we plan to pursue in the coming six months. This half 
 we are focusing on three things: safety, lifetime 
 management, and static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


 quote from the document:

 Redoing compiler code into lowerings and __traits-based 
 introspection that leverage client code, thus moving 
 compiler smarts into simpler library facilities


 To simplify introspection with library traits that use the 
 compiler "__traits()" someone has to remove the restrictions 
 related to protection attributes. This is not a new topic. 
 Without this, the new library traits won't work well and 
 people won't use them.


 IIRC, it was already agreed that they had to be removed and 
 would be soon, but we couldn't do it right away either because 
 of code breakage or because it was a point release that was 
 trying to get out the door. I'm thinking that it's supposed to 
 be fixed in 2.073, but I'm not 100% sure..

 - Jonathan M Davis


I don't known what did you decide in intern but when the 
discussion between users was hot (just after version 2.071.1 I 
think) I've proposed that: 
https://github.com/BBasile/DIPs/blob/3d5e3f81c541c6e23c69555a230b4d42a7bb6de6/DIPs/DIP8484.md

There's no need to DIP this, the idea is just to add an optional 
parameter that remove the compliance with the protection 
attributes. Anyway if this or any alternative is planned for the 
next version that's perfect.
Jan 05 2017
parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 01/05/2017 11:00 AM, Basile B. wrote:

 I don't known what did you decide in intern but when the discussion
 between users was hot (just after version 2.071.1 I think) I've proposed
 that:
 https://github.com/BBasile/DIPs/blob/3d5e3f81c541c6e23c69555a230b4d42a7bb6de6/DIPs/DIP8484.md


This is superfluous by now. We figured that allowing access to private
fields wouldn't clash with important optimizations, so it can be allowed
via traits.
The visibility of allMembers was adjusted in
https://github.com/dlang/dmd/pull/6078.
All access checks will go away once the visibility changes have been
fully deprecated. So far those changes were adopted fairly slow (not
even phobos has fixed them all), hence we haven't yet switched over to
the new visibility semantics.

-Martin
Jan 07 2017
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/07/2017 02:55 PM, Martin Nowak wrote:

 On 01/05/2017 11:00 AM, Basile B. wrote:

 I don't known what did you decide in intern but when the discussion
 between users was hot (just after version 2.071.1 I think) I've proposed
 that:
 https://github.com/BBasile/DIPs/blob/3d5e3f81c541c6e23c69555a230b4d42a7bb6de6/DIPs/DIP8484.md


 This is superfluous by now. We figured that allowing access to private
 fields wouldn't clash with important optimizations, so it can be allowed
 via traits.
 The visibility of allMembers was adjusted in
 https://github.com/dlang/dmd/pull/6078.
 All access checks will go away once the visibility changes have been
 fully deprecated. So far those changes were adopted fairly slow (not
 even phobos has fixed them all), hence we haven't yet switched over to
 the new visibility semantics.

 -Martin


Oh, now I remember. Yes, introspection works in "sudo" mode - all 
information is available to it, including what's private and what isn't 
:o). Thanks Martin for fielding this and other questions. -- Andrei
Jan 07 2017
prev sibling parent bitwise <bitwise.pvt gmail.com> writes:
On Saturday, 7 January 2017 at 19:55:30 UTC, Martin Nowak wrote:

 On 01/05/2017 11:00 AM, Basile B. wrote:

 I don't known what did you decide in intern but when the 
 discussion
 between users was hot (just after version 2.071.1 I think) 
 I've proposed
 that:
 https://github.com/BBasile/DIPs/blob/3d5e3f81c541c6e23c69555a230b4d42a7bb6de6/DIPs/DIP8484.md


 This is superfluous by now. We figured that allowing access to 
 private
 fields wouldn't clash with important optimizations, so it can 
 be allowed
 via traits.
 The visibility of allMembers was adjusted in
 https://github.com/dlang/dmd/pull/6078.
 All access checks will go away once the visibility changes have 
 been
 fully deprecated. So far those changes were adopted fairly slow 
 (not
 even phobos has fixed them all), hence we haven't yet switched 
 over to
 the new visibility semantics.

 -Martin


Awesome!

I tried to write a whole-module reflection tool, but was unable 
to finish satisfactorily due to the requirement that code 
actually be included in the module itself in order to reflect all 
it's members.
Jan 08 2017
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/04/2017 11:43 PM, Basile B. wrote:

 To simplify introspection with library traits that use the compiler
 "__traits()" someone has to remove the restrictions related to
 protection attributes. This is not a new topic. Without this, the new
 library traits won't work well and people won't use them.


Is this formalized in bugzilla? -- Andrei
Jan 07 2017
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 01/05/2017 05:43 AM, Basile B. wrote:

 To simplify introspection with library traits that use the compiler
 "__traits()" someone has to remove the restrictions related to
 protection attributes. This is not a new topic. Without this, the new
 library traits won't work well and people won't use them.


That's already what we decided in September, so where is the problem?
http://forum.dlang.org/post/ymkehalxcigswvltlfjj forum.dlang.org
https://github.com/dlang/dmd/pull/6111
Jan 07 2017
prev sibling next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:

 We release a brief Vision document summarizing the main goals 
 we plan to pursue in the coming six months. This half we are 
 focusing on three things: safety, lifetime management, and 
 static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


Do we have a list of "high-impact research projects"?
Jan 04 2017
prev sibling next sibling parent reply Anton <anton.dutov gmail.com> writes:
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:

 We release a brief Vision document summarizing the main goals 
 we plan to pursue in the coming six months. This half we are 
 focusing on three things: safety, lifetime management, and 
 static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


dub registry required review
1. By myself current page rename to "last updates", and "Main" 
may be (scoped) category view?
IMHO main page currently unfriendly

2. dub registry search unexpected
i'm looking for network libs, entered "net" and take:
...
freeimage
dyaml
...
???
Than query for "network", very different result
Jan 06 2017
next sibling parent Anton <anton.dutov gmail.com> writes:
P/S
strange search one of cases why registry has a lot of similar 
projects
Jan 06 2017
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 01/06/2017 11:09 PM, Anton wrote:

 On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu wrote:

 We release a brief Vision document summarizing the main goals we plan
 to pursue in the coming six months. This half we are focusing on three
 things: safety, lifetime management, and static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


 
 dub registry required review
 1. By myself current page rename to "last updates", and "Main" may be
 (scoped) category view?
 IMHO main page currently unfriendly
 
 2. dub registry search unexpected
 i'm looking for network libs, entered "net" and take:
 ...
 freeimage
 dyaml
 ...


Thanks, we are aware of the various limitations, hence it'll be a major
priority to improve the site. Improving search and tagging is one bigger
aspect of that, distinguishing high quality packages another one.

-Martin
Jan 07 2017
prev sibling next sibling parent Brian <zoujiaqing gmail.com> writes:
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:

 We release a brief Vision document summarizing the main goals 
 we plan to pursue in the coming six months. This half we are 
 focusing on three things: safety, lifetime management, and 
 static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


Dlang should strive to improve the standard library, such as 
Python, go, rust.
Jan 08 2017
prev sibling next sibling parent reply Brian <zoujiaqing gmail.com> writes:
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:

 We release a brief Vision document summarizing the main goals 
 we plan to pursue in the coming six months. This half we are 
 focusing on three things: safety, lifetime management, and 
 static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


I hope dlang can support QT5 binding
Jan 08 2017
parent Jonathan M Davis via Digitalmars-d-announce writes:
On Sunday, January 08, 2017 18:06:53 Brian via Digitalmars-d-announce wrote:

 On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu

 wrote:

 We release a brief Vision document summarizing the main goals
 we plan to pursue in the coming six months. This half we are
 focusing on three things: safety, lifetime management, and
 static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


 I hope dlang can support QT5 binding


Binding to Qt in general is really nasty in comparison to a lot of C++ code,
since Qt does stuff like have its own preprocessor to generate additional
code so that signals and slots work. We had qtd (which did Qt4), but it
seems to have lost all its contributors and died off a few years ago, and it
seems to have used Qt Jambi stuff (or at least been based on it) and Qt
Jambi doesn't seem to have ever made the transition to Qt5. So, I don't know
how possible it would be to get qtd to work with Qt5, even if the original
contributors were still working on it (but it doesn't seem to compile now,
so it's not even currently viable for Qt4). I think that someone put up a
solution on code.dlang.org that involves QML, but I have no idea how well it
works or how complete it is (personally, I have less than zero interest in
QML).

I've actually started work on a solution for binding Qt5 to D, because I
have something I'm working on that uses Qt, and I'm sick of doing the GUI
portion in C++. So, I may end up releasing a Qt5 bindings project at some
point here, but I'm making no promises.

- Jonathan M Davis
Jan 08 2017
prev sibling next sibling parent reply Andrew Browne <dersaidin gmail.com> writes:
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:

 We release a brief Vision document summarizing the main goals 
 we plan to pursue in the coming six months. This half we are 
 focusing on three things: safety, lifetime management, and 
 static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


Is there a design document for how D will achieve safety with 
nogc?
How does D plan to prevent leaks, use-after-free, double-free 
bugs when not using the GC?

Will  nogc also have first class support in the language?
Afaik the GC is currently needed for language features like array 
concatenation. Will features like array concatentation still work 
with  nogc?
GC allocations have a keyword 'new' (afaik 'new' currently never 
means anything other than GC allocation). Will we be able to do 
 nogc allocations by the 'new' keyword?

Is the same code always expected to work with/without  nogc?
Jan 12 2017
parent reply Jonathan M Davis via Digitalmars-d-announce writes:
On Thursday, January 12, 2017 21:57:37 Andrew Browne via Digitalmars-d-
announce wrote:

 On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu

 wrote:

 We release a brief Vision document summarizing the main goals
 we plan to pursue in the coming six months. This half we are
 focusing on three things: safety, lifetime management, and
 static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


 Is there a design document for how D will achieve safety with
 nogc?
 How does D plan to prevent leaks, use-after-free, double-free
 bugs when not using the GC?


Part of the reason that we have the GC in D is because of the safety
guarantees that you can have with a GC that you can't have with mechanisms
like malloc and free. Some amount of  nogc code can be  safe, but some of it
will never be able to be  safe. e.g. the very nature of malloc and free
makes  safe impossible in the general case. It's trivial for a piece of code
to free something that's currently in use by other code. If they're
constrained within a ref-counting system, then  safety becomes more
possible, but even then, when you have to start worrying about stuff like
weak references in order to get around circular reference problems, it gets
dicey if not impossible to make it fully  safe. It might be possible to
guarantee safety if you have a whole bunch of extra constraints like Rust
does with its borrowing stuff, but we're not going to add something like
that to D, because it's too complicated on top of everything else that we
already have.

I fully expect that certain idioms will be in place to help maintain  safety
in  nogc code, but to some extent, by abandoning the GC, you're abandoning
 safety - or at least you're making a lot more of your code need to be
 trusted, and you can rely less on the compiler to guarantee  safety for
you. Taking the freeing of memory out of the hands of the programmer like
happens with the GC is _huge_ in guaranteeing the memory safety of code.


 Will  nogc also have first class support in the language?


And what do you mean my first class support? Some features require the GC,
and I wouldn't expect it to ever be otherwise. Giving up the GC means giving
up on certain features. We don't want that list to be longer that it needs
to be, but some stuff fundamentally needs the GC to do what it does.


 Afaik the GC is currently needed for language features like array
 concatenation. Will features like array concatentation still work
 with  nogc?


I don't see how it possibly could given how dynamic arrays work in D. It
would have to have some sort of reference counting mechanism, which would
likely be a nightmare with slicing and certainly does not at all play well
with how low level D arrays are. We may very well get some sort of
ref-counted array type that has concatenation, but it would be a library
construct rather than in the language, because it doesn't need to be in the
language, and the built-in arrays would not be affected by it.


 GC allocations have a keyword 'new' (afaik 'new' currently never
 means anything other than GC allocation). Will we be able to do
  nogc allocations by the 'new' keyword?


I very much doubt it. Constructing objects into memory is done via emplace,
which is a library construct, and there's really no need for it to be in the
language. As it is, if we were doing things from scratch, new probably
wouldn't even be a keyword. It would likely be a library construct in
druntime, because D is powerful enough that new doesn't need to be in the
language to do what it does. And in general, at this point, Walter and
Andrei don't want to put stuff in the language unless it actually needs to
be there. If it can be done with a library, it will be done with a library.
The only reason that they decided that we needed some sort of ref-counting
mechanism in the language is because they decided that it wasn't actually
possible to make it fully  safe without it being part of the language. And
even then, I'm not sure that the intention is that the ref-counting
mechanism use anything other than the GC. It's not yet clear what it's going
to look like, but previously, the talk was using the GC to take care of
circular references, which would mean that the memory was still GC-allocated
even if it were ref-counted. We'll have to wait and see though.


 Is the same code always expected to work with/without  nogc?


That would depend entirely on the code. std.experimental.allocator has a GC
allocator. So, code that is designed around it could work with the GC or
without. But the whole mechanism of newing something up and then not
worrying about ownership which happens by default with the GC doesn't play
at all nicely with how memory has to be managed via other mechanisms like
malloc and free. I don't think that it's at all reasonable to expect that
code that is written with the idea that its memory will be managed by the GC
will also work without the GC. Code that isn't managing memory directly
shouldn't care - and that's a lot of code (especially once lazy ranges are
in the mix) - but I think that it's pretty clear that there's plenty of code
that simply can't just swap out its allocation mechanism and still work
properly. In general, code needs to be written with that in mind for it to
work, and even then, there are limits given how different various memory
management mechanisms are.

- Jonathan M Davis
Jan 12 2017
next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Thu, 12 Jan 2017 20:02:38 -0800, Jonathan M Davis via
Digitalmars-d-announce wrote:

 I don't see how it possibly could given how dynamic arrays work in D. It
 would have to have some sort of reference counting mechanism, which
 would likely be a nightmare with slicing


On that topic, D's arrays would play nicer with both refcounting *and* 
modern garbage collectors if they were structured as base, offset, length 
instead of start, length. You could put metadata just before the start of 
the array, including the reference count.
Jan 12 2017
next sibling parent Jonathan M Davis via Digitalmars-d-announce writes:
On Friday, January 13, 2017 05:33:07 Chris Wright via Digitalmars-d-announce 
wrote:

 On Thu, 12 Jan 2017 20:02:38 -0800, Jonathan M Davis via

 Digitalmars-d-announce wrote:

 I don't see how it possibly could given how dynamic arrays work in D. It
 would have to have some sort of reference counting mechanism, which
 would likely be a nightmare with slicing


 On that topic, D's arrays would play nicer with both refcounting *and*
 modern garbage collectors if they were structured as base, offset, length
 instead of start, length. You could put metadata just before the start of
 the array, including the reference count.


It's actually really nice as well as performant for D's dynamic arrays to be
the way that they are. Adding any kind of reference count into them would
add overhead as well as not play nicely when you're doing stuff like slicing
pointers or static arrays, which should definitely not be ref-counted. If
you're willing to use the GC, they way that D's dynamic arrays work right
now is fantastic. And even if you're not willing to use the GC, the way they
work is great if you have other code managing their memory appropriately and
just don't use the concatentation or appending operations. Plenty of code
would not want any ref-counting to be going on when passing a dynamic array
around.

Having a ref-counted object that's like an array in addition to D's current
dynamic arrays would be fine and great for some programs, but I sure
wouldn't want to lose what we have now.

- Jonathan M Davis
Jan 12 2017
prev sibling next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 13 January 2017 at 05:33:07 UTC, Chris Wright wrote:

 On Thu, 12 Jan 2017 20:02:38 -0800, Jonathan M Davis via 
 Digitalmars-d-announce wrote:

 I don't see how it possibly could given how dynamic arrays 
 work in D. It would have to have some sort of reference 
 counting mechanism, which would likely be a nightmare with 
 slicing


 On that topic, D's arrays would play nicer with both 
 refcounting *and* modern garbage collectors if they were 
 structured as base, offset, length instead of start, length. 
 You could put metadata just before the start of the array, 
 including the reference count.


I know that you mean for the general case, but the structure you 
describe is the same as `std.experimental.ndclice`s Slice!(1,T*): 
pointer, length, stride triplet. This would also work with higher 
dimensional Slices as well.

Combine that with prefix allocator ét voilá.
Jan 13 2017
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Friday, 13 January 2017 at 05:33:07 UTC, Chris Wright wrote:

 On that topic, D's arrays would play nicer with both 
 refcounting *and* modern garbage collectors if they were 
 structured as base, offset, length instead of start, length.


That might be slower sometimes as slices wouldn't fit in two 
registers then.


 You could put metadata just before the start of the array, 
 including the reference count.


Yes, but GC arrays already do that with GC metadata (alloc size) 
without having offset, so that technique could in theory be done 
with RC too. It's a bit mysterious how the base address is found, 
would be nice to have some clear docs on this to point to.
Jan 13 2017
parent Nick Treleaven <nick geany.org> writes:
On Friday, 13 January 2017 at 12:53:16 UTC, Nick Treleaven wrote:

 On Friday, 13 January 2017 at 05:33:07 UTC, Chris Wright wrote:

 On that topic, D's arrays would play nicer with both 
 refcounting *and* modern garbage collectors if they were 
 structured as base, offset, length instead of start, length.


 That might be slower sometimes as slices wouldn't fit in two 
 registers then.


Although for custom data structures, offset & length could often 
share one register. Then the magic looking up of the base address 
can be avoided, saving time.
Jan 13 2017
prev sibling parent Andrew Browne <dersaidin gmail.com> writes:
On Friday, 13 January 2017 at 04:02:38 UTC, Jonathan M Davis 
wrote:

 On Thursday, January 12, 2017 21:57:37 Andrew Browne via 
 Digitalmars-d- announce wrote:

 On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei 
 Alexandrescu

 wrote:

 We release a brief Vision document summarizing the main 
 goals we plan to pursue in the coming six months. This half 
 we are focusing on three things: safety, lifetime 
 management, and static introspection.

 https://wiki.dlang.org/Vision/2017H1


 Andrei


 Is there a design document for how D will achieve safety with
 nogc?
 How does D plan to prevent leaks, use-after-free, double-free
 bugs when not using the GC?


 Part of the reason that we have the GC in D is because of the 
 safety guarantees that you can have with a GC that you can't 
 have with mechanisms like malloc and free. Some amount of  nogc 
 code can be  safe, but some of it will never be able to be 
  safe. e.g. the very nature of malloc and free makes  safe 
 impossible in the general case.


This is why I ask. Because the vision document says

"2.  nogc: Use of D without a garbage collector, most likely by 
using reference counting and related methods Unique/Weak 
references) for reclamation of resources. This task is made 
challenging by the safety requirement."

It sounds like  safe  nogc code is the goal. I know it is 
challenging, I'd like to know if there is a plan/design for how 
to achieve this.


 It's trivial for a piece of code to free something that's 
 currently in use by other code. If they're constrained within a 
 ref-counting system, then  safety becomes more possible, but 
 even then, when you have to start worrying about stuff like 
 weak references in order to get around circular reference 
 problems, it gets dicey if not impossible to make it fully 
  safe.


Yep, circular references are a difficulty of ref-counting. Is 
there a plan/design for how to handle this?


 It might be possible to guarantee safety if you have a whole 
 bunch of extra constraints like Rust does with its borrowing 
 stuff, but we're not going to add something like that to D, 
 because it's too complicated on top of everything else that we 
 already have.


So that level of safety is just not a goal of D? If I want memory 
safe code without a GC, should I just use Rust?


 I fully expect that certain idioms will be in place to help 
 maintain  safety in  nogc code, but to some extent, by 
 abandoning the GC, you're abandoning  safety - or at least 
 you're making a lot more of your code need to be  trusted, and 
 you can rely less on the compiler to guarantee  safety for you. 
 Taking the freeing of memory out of the hands of the programmer 
 like happens with the GC is _huge_ in guaranteeing the memory 
 safety of code.


 Will  nogc also have first class support in the language?


 And what do you mean my first class support? Some features 
 require the GC, and I wouldn't expect it to ever be otherwise. 
 Giving up the GC means giving up on certain features. We don't 
 want that list to be longer that it needs to be, but some stuff 
 fundamentally needs the GC to do what it does.


That is what I meant. The next questions are examples of what I 
meant.


 Afaik the GC is currently needed for language features like 
 array concatenation. Will features like array concatentation 
 still work with  nogc?


 I don't see how it possibly could given how dynamic arrays work 
 in D. It would have to have some sort of reference counting 
 mechanism, which would likely be a nightmare with slicing and 
 certainly does not at all play well with how low level D arrays 
 are. We may very well get some sort of ref-counted array type 
 that has concatenation, but it would be a library construct 
 rather than in the language, because it doesn't need to be in 
 the language, and the built-in arrays would not be affected by 
 it.


 GC allocations have a keyword 'new' (afaik 'new' currently 
 never means anything other than GC allocation). Will we be 
 able to do  nogc allocations by the 'new' keyword?


 I very much doubt it. Constructing objects into memory is done 
 via emplace, which is a library construct, and there's really 
 no need for it to be in the language. As it is, if we were 
 doing things from scratch, new probably wouldn't even be a 
 keyword. It would likely be a library construct in druntime, 
 because D is powerful enough that new doesn't need to be in the 
 language to do what it does. And in general, at this point, 
 Walter and Andrei don't want to put stuff in the language 
 unless it actually needs to be there. If it can be done with a 
 library, it will be done with a library. The only reason that 
 they decided that we needed some sort of ref-counting mechanism 
 in the language is because they decided that it wasn't actually 
 possible to make it fully  safe without it being part of the 
 language. And even then, I'm not sure that the intention is 
 that the ref-counting mechanism use anything other than the GC. 
 It's not yet clear what it's going to look like, but 
 previously, the talk was using the GC to take care of circular 
 references, which would mean that the memory was still 
 GC-allocated even if it were ref-counted. We'll have to wait 
 and see though.


 Is the same code always expected to work with/without  nogc?


 That would depend entirely on the code. 
 std.experimental.allocator has a GC allocator. So, code that is 
 designed around it could work with the GC or without. But the 
 whole mechanism of newing something up and then not worrying 
 about ownership which happens by default with the GC doesn't 
 play at all nicely with how memory has to be managed via other 
 mechanisms like malloc and free. I don't think that it's at all 
 reasonable to expect that code that is written with the idea 
 that its memory will be managed by the GC will also work 
 without the GC. Code that isn't managing memory directly 
 shouldn't care - and that's a lot of code (especially once lazy 
 ranges are in the mix) - but I think that it's pretty clear 
 that there's plenty of code that simply can't just swap out its 
 allocation mechanism and still work properly. In general, code 
 needs to be written with that in mind for it to work, and even 
 then, there are limits given how different various memory 
 management mechanisms are.

 - Jonathan M Davis


Yep, I know there are a lot of things that become hard to make 
safe without a GC.
That is why, I'd like to know what is a plan/design for achieving 
 safe  nogc code? What is not planned to be supported?
Jan 16 2017
prev sibling parent qznc <qznc web.de> writes:
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:

 We release a brief Vision document summarizing the main goals 
 we plan to pursue in the coming six months. This half we are 
 focusing on three things: safety, lifetime management, and 
 static introspection.

 https://wiki.dlang.org/Vision/2017H1



I guess the 2017H1 document is quite final now. Why not turn that 
into a blog post? It could be official (by the leaders) or 
informal (interview with Andrei).
Jan 19 2017