www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Release D 2.079.0

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Glad to announce D 2.079.0.

This release comes with experimental ` nogc` exception throwing
(-dip1008), a lazily initialized GC, better support for minimal
runtimes, and an experimental Windows toolchain based on the lld
linker and MinGW import libraries. See the changelog for more details.

Thanks to everyone involved in this 👏
https://dlang.org/changelog/2.079.0.html#contributors.

http://dlang.org/download.html
http://dlang.org/changelog/2.079.0.html

- -Martin
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlqZ/1wACgkQsnOBFhK7
GTkF4hAAqIT7eDN5TpG3WwVQEWNtv1Z2P3/2j75TOq5UA+R93y0mzyrCvaGPhmnc
81DakDAsvf73Ed+Yr3xcVEuL6Uy9M3vCMOXT+maeOz7Ux+wQItUBvVs2CmMom9TU
7somFnXZ9+4rIlNePh2bIshleWaBmfbwxCla1FheY+geoQvsKuky9qOv3GJEK9dJ
RDM3Hc70m+88aKDxZ/4HtA0mctR49nwJxDg6OKS4A2V6QxiDN0e0TWxRoH/xCCZG
mnhvrYG2nhSEDVVehqJePm7p6dhsfBOv+8FtiaboRB72OB2D4Jl4PVJV61neihfj
uxJWY6gIGn2JIiav0wr0SsXy1bM58GvJ71e7YLdYjez5+IQ57ydaVMATRGoPgWi2
nvgkn+/izcHUiXm6srcJvkXMLcmUn3tpFyhZv/YC681Sulfe5UfxTDVPWFQn7AM6
etm7XbF74EpelWo0UUX/2pppxNpjkKcxjnmli8pR0eKL4LOTtZ3CJOnsiw/jUoyo
7XekHL1cFBD8r6txHEwkpVdokEeNNxvZoB0dZ07mJGGgr5fwWVA++W3Xkho1hAcm
+AgAAkmM7E2ZkH2vrz4jgO6N57L/LXoz8UsV8p2xqVKz2iWKi1C+UjKXFn/0wx9J
FqT3zQ791PeaEbBX+AgqTw4BQMjvbsxlENkZc8uKwJvLIdJRSuQ=
=4XFa
-----END PGP SIGNATURE-----
Mar 02 2018
next sibling parent psychoticRabbit <meagain meagain.com> writes:
On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:

 Glad to announce D 2.079.0.

 This release comes with experimental ` nogc` exception throwing 
 (-dip1008), a lazily initialized GC, better support for minimal 
 runtimes, and an experimental Windows toolchain based on the 
 lld linker and MinGW import libraries. See the changelog for 
 more details.

 Thanks to everyone involved in this 👏 
 https://dlang.org/changelog/2.079.0.html#contributors.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.079.0.html

 - -Martin


Well done to all! (especially the work on the toolchain)

I'm going to download it and test that import syntax 
thingo...just to make sure it really is gone ;-)
Mar 02 2018
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:

 Glad to announce D 2.079.0.


I've got a blog post coming on this in a few hours, so I would 
ask anyone considering sharing this on /r/programming before then 
to please refrain :-)
Mar 02 2018
parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 3 March 2018 at 02:35:21 UTC, Mike Parker wrote:


 I've got a blog post coming on this in a few hours, so I would 
 ask anyone considering sharing this on /r/programming before 
 then to please refrain :-)


And it's live:

The blog:
https://dlang.org/blog/2018/03/03/dmd-2-079-0-released/

Reddit:
https://www.reddit.com/r/programming/comments/81pqwb/dmdthe_d_reference_compiler20790_released/
Mar 03 2018
parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 03/03/2018 01:05 PM, Mike Parker wrote:

 The blog:
 https://dlang.org/blog/2018/03/03/dmd-2-079-0-released/


Could you please add a big visible "experimental" to the lld-link
toolchain. It still has a lot of bugs and isn't ready for primetime.
Mar 03 2018
parent Mike Parker <aldacron gmail.com> writes:
On Saturday, 3 March 2018 at 13:22:07 UTC, Martin Nowak wrote:

 On 03/03/2018 01:05 PM, Mike Parker wrote:

 The blog: 
 https://dlang.org/blog/2018/03/03/dmd-2-079-0-released/


 Could you please add a big visible "experimental" to the 
 lld-link toolchain. It still has a lot of bugs and isn't ready 
 for primetime.


Done. Thanks! Maybe you or someone else could answer this reddit 
comment:

https://www.reddit.com/r/programming/comments/81pqwb/dmdthe_d_reference_compiler20790_released/dv4ae2t/

I don't know what the plans are going forward.
Mar 03 2018
prev sibling next sibling parent Mengu <mengukagan gmail.com> writes:
On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:

 Glad to announce D 2.079.0.

 This release comes with experimental ` nogc` exception throwing 
 (-dip1008), a lazily initialized GC, better support for minimal 
 runtimes, and an experimental Windows toolchain based on the 
 lld linker and MinGW import libraries. See the changelog for 
 more details.

 Thanks to everyone involved in this 👏 
 https://dlang.org/changelog/2.079.0.html#contributors.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.079.0.html

 - -Martin


looks like huge work was done on this release. thank you all.
Mar 03 2018
prev sibling next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:

 Glad to announce D 2.079.0.

 This release comes with experimental ` nogc` exception throwing 
 (-dip1008), a lazily initialized GC, better support for minimal 
 runtimes, and an experimental Windows toolchain based on the 
 lld linker and MinGW import libraries. See the changelog for 
 more details.

 Thanks to everyone involved in this 👏 
 https://dlang.org/changelog/2.079.0.html#contributors.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.079.0.html

 - -Martin


Is is just me or did this release just break the latest non-beta 
vibe.d? Is the Jenkins build testing the dub packages on master 
instead of the latest tag?

Atila
Mar 05 2018
next sibling parent reply Seb <seb wilzba.ch> writes:
On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote:

 On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:

 Glad to announce D 2.079.0.

 This release comes with experimental ` nogc` exception 
 throwing (-dip1008), a lazily initialized GC, better support 
 for minimal runtimes, and an experimental Windows toolchain 
 based on the lld linker and MinGW import libraries. See the 
 changelog for more details.

 Thanks to everyone involved in this 👏 
 https://dlang.org/changelog/2.079.0.html#contributors.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.079.0.html

 - -Martin


 Is is just me or did this release just break the latest 
 non-beta vibe.d? Is the Jenkins build testing the dub packages 
 on master instead of the latest tag?

 Atila


https://github.com/vibe-d/vibe.d/issues/2058
Mar 05 2018
parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 5 March 2018 at 17:47:13 UTC, Seb wrote:

 On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote:

 On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:

 Glad to announce D 2.079.0.

 This release comes with experimental ` nogc` exception 
 throwing (-dip1008), a lazily initialized GC, better support 
 for minimal runtimes, and an experimental Windows toolchain 
 based on the lld linker and MinGW import libraries. See the 
 changelog for more details.

 Thanks to everyone involved in this 👏 
 https://dlang.org/changelog/2.079.0.html#contributors.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.079.0.html

 - -Martin


 Is is just me or did this release just break the latest 
 non-beta vibe.d? Is the Jenkins build testing the dub packages 
 on master instead of the latest tag?

 Atila


 https://github.com/vibe-d/vibe.d/issues/2058


It's great that there's an issue for vibe.

This doesn't change the fact that right now, somebody trying D 
for the 1st time with the latest official compiler will get an 
error if they try out the most popular dub package that I know of 
if they follow the instructions on code.dlang.org.

It also doesn't change that I can't upgrade dmd on our CI at work 
because it can't compile vibe unless I change dozens of dub.sdl 
files to use a beta version. This breaks semver!

I found out about this after removing a dependency on 
stdx.data.json since dmd >= 2.078.0 broke it (by breaking 
taggedalgebraic. Yes, I filed a bug.). I can upgrade from 2.077.1 
to 2.078.3,but not 2.079.0.

I'd have a snowball's chance in hell convincing anyone at a 
"regular" company of adopting D if anyone there even imagined any 
of the above could happen.

We have to do better than this.

Atila
Mar 05 2018
next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote:

 I'd have a snowball's chance in hell convincing anyone at a 
 "regular" company of adopting D if anyone there even imagined 
 any of the above could happen.

 We have to do better than this.

 Atila


Fair enough. Doing better is always a good thing to aim for.

But really, who use something 'just released' in production?

As far as I'm concerned, every release is a beta... even if the 
beta tag is removed.

The real problem is something you mentioned .. new comers 
downloading the latest release..which as I mentioned, is really a 
beta.

But that's just the way software developement works these days - 
sadly - ship quickly, and ship often. As a result, we're all just 
testers for the latest release.
Mar 05 2018
parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 6 March 2018 at 00:08:33 UTC, psychoticRabbit wrote:

 On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote:

 I'd have a snowball's chance in hell convincing anyone at a 
 "regular" company of adopting D if anyone there even imagined 
 any of the above could happen.

 We have to do better than this.

 Atila


 Fair enough. Doing better is always a good thing to aim for.

 But really, who use something 'just released' in production?


This is beside the point. Anyone who hears about vibe.d and goes 
to download the compiler to try it out will fail to get it to 
compile with the official instructions on how to do so.

It's hard enough to convince people to adopt a new programming 
language when everything works as intended.

Atila
Mar 06 2018
prev sibling next sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 06.03.2018 um 00:40 schrieb Atila Neves:

 (...)
 
 This doesn't change the fact that right now, somebody trying D for the 
 1st time with the latest official compiler will get an error if they try 
 out the most popular dub package that I know of if they follow the 
 instructions on code.dlang.org.
 
 It also doesn't change that I can't upgrade dmd on our CI at work 
 because it can't compile vibe unless I change dozens of dub.sdl files to 
 use a beta version. This breaks semver!
 
 I found out about this after removing a dependency on stdx.data.json 
 since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed 
 a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0.
 
 I'd have a snowball's chance in hell convincing anyone at a "regular" 
 company of adopting D if anyone there even imagined any of the above 
 could happen.
 
 We have to do better than this.
 
 Atila
 


I tagged a RC today: 
https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/49899/

To avoid letting this sit broken I'll shorten the final testing phase, 
so that the release happens this Thursday. This is a bit unfortunate, 
because this release is a bit more disruptive than normal due to the 
switch to using vibe-core by default. So early testing with "dub upgrade 
--prerelease" in different projects is particularly valuable this time!

BTW, the problems with this release are a strong hint that we should 
rethink the inclusion approach with std.experimental. Since breaking 
changes are tied to the DMD version, it makes those modules almost 
unusable outside of toy code. Having them as a DUB package (or in 
essence, in a separate repository) on the other hand nicely decouples 
them from the compiler release and makes it possible to properly version 
them individually.
Mar 05 2018
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 6 March 2018 at 00:10:52 UTC, Sönke Ludwig wrote:

 BTW, the problems with this release are a strong hint that we 
 should rethink the inclusion approach with std.experimental. 
 Since breaking changes are tied to the DMD version, it makes 
 those modules almost unusable outside of toy code. Having them 
 as a DUB package (or in essence, in a separate repository) on 
 the other hand nicely decouples them from the compiler release 
 and makes it possible to properly version them individually.


Additional evidence: std.experimental.ndslice -> libmir.
Mar 05 2018
prev sibling next sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On 3/5/18 15:40, Atila Neves wrote:

 On Monday, 5 March 2018 at 17:47:13 UTC, Seb wrote:

 On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote:

 On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:

 Glad to announce D 2.079.0.

 This release comes with experimental ` nogc` exception throwing
 (-dip1008), a lazily initialized GC, better support for minimal
 runtimes, and an experimental Windows toolchain based on the lld
 linker and MinGW import libraries. See the changelog for more details.

 Thanks to everyone involved in this 👏
 https://dlang.org/changelog/2.079.0.html#contributors.

 http://dlang.org/download.html http://dlang.org/changelog/2.079.0.html

 - -Martin


 Is is just me or did this release just break the latest non-beta
 vibe.d? Is the Jenkins build testing the dub packages on master
 instead of the latest tag?

 Atila


 https://github.com/vibe-d/vibe.d/issues/2058


 It's great that there's an issue for vibe.

 This doesn't change the fact that right now, somebody trying D for the
 1st time with the latest official compiler will get an error if they try
 out the most popular dub package that I know of if they follow the
 instructions on code.dlang.org.

 It also doesn't change that I can't upgrade dmd on our CI at work
 because it can't compile vibe unless I change dozens of dub.sdl files to
 use a beta version. This breaks semver!

 I found out about this after removing a dependency on stdx.data.json
 since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed
 a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0.

 I'd have a snowball's chance in hell convincing anyone at a "regular"
 company of adopting D if anyone there even imagined any of the above
 could happen.

 We have to do better than this.

 Atila


May I make a recommendation? Only upgrade to the 2.0xx.2[.3] releases. 
You'll have to wait a month or so for the latest features, but by then 
the important packages will have been upgraded and the regressions 
(mostly) worked out. It's kind of like the old saying about Microsoft 
software. "Never use the first version of anything". If we treat the .0 
releases as "v1" then it fits. :)

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;
Mar 05 2018
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 6 March 2018 at 06:53:30 UTC, Adam Wilson wrote:

 On 3/5/18 15:40, Atila Neves wrote:

 On Monday, 5 March 2018 at 17:47:13 UTC, Seb wrote:

 On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote:

 On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak 
 wrote:

 [...]


 Is is just me or did this release just break the latest 
 non-beta
 vibe.d? Is the Jenkins build testing the dub packages on 
 master
 instead of the latest tag?

 Atila


 https://github.com/vibe-d/vibe.d/issues/2058


 It's great that there's an issue for vibe.

 This doesn't change the fact that right now, somebody trying D 
 for the
 1st time with the latest official compiler will get an error 
 if they try
 out the most popular dub package that I know of if they follow 
 the
 instructions on code.dlang.org.

 It also doesn't change that I can't upgrade dmd on our CI at 
 work
 because it can't compile vibe unless I change dozens of 
 dub.sdl files to
 use a beta version. This breaks semver!

 I found out about this after removing a dependency on 
 stdx.data.json
 since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. 
 Yes, I filed
 a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0.

 I'd have a snowball's chance in hell convincing anyone at a 
 "regular"
 company of adopting D if anyone there even imagined any of the 
 above
 could happen.

 We have to do better than this.

 Atila


 May I make a recommendation? Only upgrade to the 2.0xx.2[.3] 
 releases. You'll have to wait a month or so for the latest 
 features, but by then the important packages will have been 
 upgraded and the regressions (mostly) worked out. It's kind of 
 like the old saying about Microsoft software. "Never use the 
 first version of anything". If we treat the .0 releases as "v1" 
 then it fits. :)


The problem with that is I was waiting for 2.079.0 since it fixes 
a bug that prevented me from upgrading to any of the 2.078.x 
releases on Windows.

And then there's the fact that the last time I had issues 
upgrading gcc or clang was... never.

I'm more than ok with compiler upgrades breaking my code when it 
was wrong in the 1st place, or with language updates breaking 
code but making the situation better as a whole. That's not 
what's been happening to me with the last few versions.

Atila
Mar 06 2018
parent Martin Nowak <code dawg.eu> writes:
On Tuesday, 6 March 2018 at 11:10:49 UTC, Atila Neves wrote:

 The problem with that is I was waiting for 2.079.0 since it 
 fixes a bug that prevented me from upgrading to any of the 
 2.078.x releases on Windows.


I think 2.078 would make an excellent starting point for a LTS 
because of the important fixes that only made it to 2.079. If 
anyone is interested to backport fixes and maintain such a 
source-branch, please contact me.
Mar 06 2018
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/5/18 6:40 PM, Atila Neves wrote:

 On Monday, 5 March 2018 at 17:47:13 UTC, Seb wrote:

 On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote:

 On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:

 Glad to announce D 2.079.0.

 This release comes with experimental ` nogc` exception throwing 
 (-dip1008), a lazily initialized GC, better support for minimal 
 runtimes, and an experimental Windows toolchain based on the lld 
 linker and MinGW import libraries. See the changelog for more details.

 Thanks to everyone involved in this 👏 
 https://dlang.org/changelog/2.079.0.html#contributors.

 http://dlang.org/download.html http://dlang.org/changelog/2.079.0.html

 - -Martin


 Is is just me or did this release just break the latest non-beta 
 vibe.d? Is the Jenkins build testing the dub packages on master 
 instead of the latest tag?

 Atila


 https://github.com/vibe-d/vibe.d/issues/2058


 
 It's great that there's an issue for vibe.
 
 This doesn't change the fact that right now, somebody trying D for the 
 1st time with the latest official compiler will get an error if they try 
 out the most popular dub package that I know of if they follow the 
 instructions on code.dlang.org.
 
 It also doesn't change that I can't upgrade dmd on our CI at work 
 because it can't compile vibe unless I change dozens of dub.sdl files to 
 use a beta version. This breaks semver!
 
 I found out about this after removing a dependency on stdx.data.json 
 since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed 
 a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0.
 
 I'd have a snowball's chance in hell convincing anyone at a "regular" 
 company of adopting D if anyone there even imagined any of the above 
 could happen.
 
 We have to do better than this.


std.experimental is supposed to be allowed to be broken.

That being said, I'm wondering if it wouldn't be better to have 
std.experimental be in its own repository. This allows selection of the 
dependency on std.experimental separate from phobos. It still would be 
an "official" dlang package, and might even be included in the 
distribution (the latest version anyway), and docs included on the 
website. But if needed, you could have your dub package depend on a 
prior version.

-Steve
Mar 06 2018
next sibling parent reply Martin Nowak <code dawg.eu> writes:
On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer 
wrote:

 That being said, I'm wondering if it wouldn't be better to have 
 std.experimental be in its own repository.


Just showing that phobos is not the right place to develop 
modules/packages, also mir.
IMO std.experimental provides little benefit over dub, but comes 
with many downsides.


 This allows selection of the dependency on std.experimental 
 separate from phobos.


You cannot link against diamond dependencies of different 
versions though, so we'd have to exclude it from libphobos and 
put it separately.


 It still would be an "official" dlang package, and might even 
 be included in the distribution (the latest version anyway), 
 and docs included on the website.


Not sure why inclusion in distribution is often mentioned as such 
a thing.
It's trivial and common to have separate libraries/dependencies 
in every language with a healthy ecosystem.


 But if needed, you could have your dub package depend on a 
 prior version.


http://code.dlang.org/packages/stdx-allocator ;)
Mar 06 2018
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/6/18 2:30 PM, Martin Nowak wrote:

 On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:



 But if needed, you could have your dub package depend on a prior version.


 
 http://code.dlang.org/packages/stdx-allocator ;)
 


This is the answer, vibe.d should depend on stdx-allocator.

-Steve
Mar 06 2018
parent reply Seb <seb wilzba.ch> writes:
On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer 
wrote:

 On 3/6/18 2:30 PM, Martin Nowak wrote:

 On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer 
 wrote:



 But if needed, you could have your dub package depend on a 
 prior version.


 
 http://code.dlang.org/packages/stdx-allocator ;)
 


 This is the answer, vibe.d should depend on stdx-allocator.

 -Steve


Vibe.d (and a lot of other projects) do depend on this package, 
see e.g.

https://github.com/vibe-d/vibe.d/pull/1983

Also many packages already depend on vibe.d-0.8.3, but it's in 
rc1 atm and not released as the latest stable tag yet, which is 
the reason for Atila's justified complaint.
Mar 06 2018
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 7 March 2018 at 04:02:18 UTC, Seb wrote:

 On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer 
 wrote:

 On 3/6/18 2:30 PM, Martin Nowak wrote:

 On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven 
 Schveighoffer wrote:



 But if needed, you could have your dub package depend on a 
 prior version.


 
 http://code.dlang.org/packages/stdx-allocator ;)
 


 This is the answer, vibe.d should depend on stdx-allocator.

 -Steve


 Vibe.d (and a lot of other projects) do depend on this package, 
 see e.g.

 https://github.com/vibe-d/vibe.d/pull/1983

 Also many packages already depend on vibe.d-0.8.3, but it's in 
 rc1 atm and not released as the latest stable tag yet, which is 
 the reason for Atila's justified complaint.


The point is just to persuade Sonke to do his development in the 
minor version and increase it during every vibe-d release, and 
keep the patch version for fast fixes of the latest released 
vibe-d when a new version of the compiler is being released.

The actual policy is just an ask for problems...

It's not a big deal to fix the breakage on the latest released 
vibe-d code, it's a fast process. But it's a problem in just 
coordinating the next release of vibe-d with the release of the 
compiler, if you need to do this, like in this case.

/Paolo
Mar 07 2018
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 07.03.2018 um 10:17 schrieb Paolo Invernizzi:

 On Wednesday, 7 March 2018 at 04:02:18 UTC, Seb wrote:

 On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer wrote:

 On 3/6/18 2:30 PM, Martin Nowak wrote:

 On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:



 But if needed, you could have your dub package depend on a prior 
 version.


 http://code.dlang.org/packages/stdx-allocator ;)


 This is the answer, vibe.d should depend on stdx-allocator.

 -Steve


 Vibe.d (and a lot of other projects) do depend on this package, see e.g.

 https://github.com/vibe-d/vibe.d/pull/1983

 Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm 
 and not released as the latest stable tag yet, which is the reason for 
 Atila's justified complaint.


 
 The point is just to persuade Sonke to do his development in the minor 
 version and increase it during every vibe-d release, and keep the patch 
 version for fast fixes of the latest released vibe-d when a new version 
 of the compiler is being released.
 
 The actual policy is just an ask for problems...
 
 It's not a big deal to fix the breakage on the latest released vibe-d 
 code, it's a fast process. But it's a problem in just coordinating the 
 next release of vibe-d with the release of the compiler, if you need to 
 do this, like in this case.
 
 /Paolo
 


Well, for all of the recent releases we made sure that there was no 
breakage for new compiler versions. This release was an exception, 
because I didn't manage to put out the fixed release in time. The plan 
is to have all future releases go back to the normal mode where the new 
compiler version always works.

Since std.experimental isn't involved from now on, it shouldn't even be 
necessary anymore to put out new vibe.d releases for new DMD versions, 
because DMD/Phobos already checks for regressions against vibe.d and all 
breaking changes should simply result in a deprecation warning.

As for the versioning scheme, currently almost all new releases have 
some small breaking change or deprecation. If I'd use the "minor" 
version for that, then there would be no way to signal that a release 
makes broad and more disruptive changes, such as the 0.8.0 release. But 
all of this will change, as the remaining parts get pushed to separate 
repositories one-by-one, with their own version starting at 1.0.0.
Mar 07 2018
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 7 March 2018 at 10:13:29 UTC, Sönke Ludwig wrote:


 Well, for all of the recent releases we made sure that there 
 was no breakage for new compiler versions. This release was an 
 exception, because I didn't manage to put out the fixed release 
 in time. The plan is to have all future releases go back to the 
 normal mode where the new compiler version always works.

 Since std.experimental isn't involved from now on, it shouldn't 
 even be necessary anymore to put out new vibe.d releases for 
 new DMD versions, because DMD/Phobos already checks for 
 regressions against vibe.d and all breaking changes should 
 simply result in a deprecation warning.


That's fine, thanks.


 As for the versioning scheme, currently almost all new releases 
 have some small breaking change or deprecation. If I'd use the 
 "minor" version for that, then there would be no way to signal 
 that a release makes broad and more disruptive changes, such as 
 the 0.8.0 release. But all of this will change, as the 
 remaining parts get pushed to separate repositories one-by-one, 
 with their own version starting at 1.0.0.


I understand your reasoning, but there's value in being able to 
just rapidly fix something with a new release, or just port some 
master bug-fixes into a released version branch.

DMD is experiencing a very enjoyable release process of patch 
versions, thanks to Martin and the team.

It your concern is only related to the best way to inform the 
users about a broad and disruptive change in vibe-d, I suggest to 
simply use the usual channels for that, change logs and announce 
forum.

My impression is that there's a lot of value in using patch for 
patch, instead of using patch for development, also in a zero 
major, so I maybe you should consider that change, or at least, 
investigate a little about that opportunity.

/Paolo
Mar 07 2018
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 07.03.2018 um 13:57 schrieb Paolo Invernizzi:

 On Wednesday, 7 March 2018 at 10:13:29 UTC, Sönke Ludwig wrote:
 

 Well, for all of the recent releases we made sure that there was no 
 breakage for new compiler versions. This release was an exception, 
 because I didn't manage to put out the fixed release in time. The plan 
 is to have all future releases go back to the normal mode where the 
 new compiler version always works.

 Since std.experimental isn't involved from now on, it shouldn't even 
 be necessary anymore to put out new vibe.d releases for new DMD 
 versions, because DMD/Phobos already checks for regressions against 
 vibe.d and all breaking changes should simply result in a deprecation 
 warning.


 
 That's fine, thanks.
 

 As for the versioning scheme, currently almost all new releases have 
 some small breaking change or deprecation. If I'd use the "minor" 
 version for that, then there would be no way to signal that a release 
 makes broad and more disruptive changes, such as the 0.8.0 release. 
 But all of this will change, as the remaining parts get pushed to 
 separate repositories one-by-one, with their own version starting at 
 1.0.0.


 
 I understand your reasoning, but there's value in being able to just 
 rapidly fix something with a new release, or just port some master 
 bug-fixes into a released version branch.
 
 DMD is experiencing a very enjoyable release process of patch versions, 
 thanks to Martin and the team.
 
 It your concern is only related to the best way to inform the users 
 about a broad and disruptive change in vibe-d, I suggest to simply use 
 the usual channels for that, change logs and announce forum.
 
 My impression is that there's a lot of value in using patch for patch, 
 instead of using patch for development, also in a zero major, so I maybe 
 you should consider that change, or at least, investigate a little about 
 that opportunity.
 
 /Paolo


But why wouldn't it be possible to make a quick bugfix release with the 
current scheme? It has happened in the past. Granted, if a 0.8.5-beta.1 
is already tagged, then using 0.8.5 for a quick intermediate release 
would be bad, but at that point the beta could likely also be turned 
into a full release pretty quickly.

But the point is that the development mode is currently still happening 
in a linear fashion. Starting to have (a) stable branch(es) with 
additional point releases would increase the overhead to a point where 
there wouldn't be any meaningful progress anymore, at least at this time.

Then there is the fact that 0.8.0 was developed in a parallel branch for 
quite a while. If the minor version would have been used to denote 
regular small updates, it would not have been possible to tag alpha/beta 
releases on the 0.8.x branch at all.
Mar 07 2018
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 7 March 2018 at 14:53:09 UTC, Sönke Ludwig wrote:


 But why wouldn't it be possible to make a quick bugfix release 
 with the current scheme? It has happened in the past. Granted, 
 if a 0.8.5-beta.1 is already tagged, then using 0.8.5 for a 
 quick intermediate release would be bad, but at that point the 
 beta could likely also be turned into a full release pretty 
 quickly.


Well, I don't know why, but quick is more than 30 days right now 
using the current release procedure...

https://github.com/vibe-d/vibe.d/issues/2058
https://github.com/vibe-d/vibe.d/releases

Anyway, never mind!

/Paolo
Mar 07 2018
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 07.03.2018 um 17:01 schrieb Paolo Invernizzi:

 On Wednesday, 7 March 2018 at 14:53:09 UTC, Sönke Ludwig wrote:
 

 But why wouldn't it be possible to make a quick bugfix release with 
 the current scheme? It has happened in the past. Granted, if a 
 0.8.5-beta.1 is already tagged, then using 0.8.5 for a quick 
 intermediate release would be bad, but at that point the beta could 
 likely also be turned into a full release pretty quickly.


 
 Well, I don't know why, but quick is more than 30 days right now using 
 the current release procedure...
 
 https://github.com/vibe-d/vibe.d/issues/2058
 https://github.com/vibe-d/vibe.d/releases
 
 Anyway, never mind!
 
 /Paolo


What I mean are releases like these:

https://vibed.org/blog/posts/vibe-release-0.7.11 (3 days)
https://vibed.org/blog/posts/vibe-release-0.7.28 (16 days)

There are also releases such as 0.7.29 that actually got branched out 
and was stabilized while 0.7.30 was already pushed further along on master.

But such releases were only done if really necessary, because a release, 
despite many things being automated, always has quite some overhead, 
just like maintaining parallel branches has. Depending on the work force 
and the general development speed that may be okay, but currently 
development time unfortunately is a premium.
Mar 07 2018
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/6/18 11:02 PM, Seb wrote:

 On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer wrote:

 On 3/6/18 2:30 PM, Martin Nowak wrote:

 On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:



 But if needed, you could have your dub package depend on a prior 
 version.


 http://code.dlang.org/packages/stdx-allocator ;)


 This is the answer, vibe.d should depend on stdx-allocator.

 -Steve


 
 Vibe.d (and a lot of other projects) do depend on this package, see e.g.
 
 https://github.com/vibe-d/vibe.d/pull/1983
 
 Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm 
 and not released as the latest stable tag yet, which is the reason for 
 Atila's justified complaint.


Hm... so basically this was fixed back in December, but just hadn't been 
released? I think then this seems like an unfortunate, but temporary 
problem that should be OK for the future.

In any case, I think this shows we need to move our proving grounds to 
an external package. Much better to do it that way than to couple 
breaking changes on an experimental package with dmd/phobos fixes.

-Steve
Mar 07 2018
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer 
wrote:

 That being said, I'm wondering if it wouldn't be better to have 
 std.experimental be in its own repository. This allows 
 selection of the dependency on std.experimental separate from 
 phobos. It still would be an "official" dlang package, and 
 might even be included in the distribution (the latest version 
 anyway), and docs included on the website. But if needed, you 
 could have your dub package depend on a prior version.


The entire concept needs a reexamination IMO. I just checked the 
git history, and not one module has graduated from 
std.experimental to mainline Phobos since the idea's inception in 
2014. While it's possible that none of the modules are ready, 
logger has been there for four years now. I was against changing 
how experimental is handled in the past, but I recently have 
started to rethink how we promote modules.

Also, if you'll allow me to have crazy ideas for a moment, one 
wonders why we shouldn't just release Phobos itself through dub? 
Rust makes people use their build tool, why not us?
Mar 06 2018
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 06, 2018 at 08:50:37PM +0000, Jack Stouffer via
Digitalmars-d-announce wrote:
[...]

 Also, if you'll allow me to have crazy ideas for a moment, one wonders
 why we shouldn't just release Phobos itself through dub? Rust makes
 people use their build tool, why not us?


Please don't. I dread the day my daily dmd toolchain update script will
have to depend on dub just to be able to build a working compiler.

But personal preferences aside, one blocker to this is that dmd and
phobos (as well as druntime) development often go in lockstep, and
sometimes breaking transitions must be coordinated between them so that
git master is always buildable.  If dmd and phobos were separate repos,
it would make this coordination much, much, more difficult.

(Though, on second thoughts, that's not necessarily a bad thing, as it
will force us to actually face these issues and make Phobos buildable
with multiple compiler versions, which currently is not well supported,
if it works at all, because of said interdependence. This would also
force us to dogfood our release / deprecation processeses, which will
allow us to notice problems early and to experience what end users would
experience when transitioning between compiler versions. It *will* add
more workload to an already thin Phobos dev team, though. So there's
that.)


T

-- 
Why are you blatanly misspelling "blatant"? -- Branden Robinson
Mar 06 2018
prev sibling next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote:

 Also, if you'll allow me to have crazy ideas for a moment, one 
 wonders why we shouldn't just release Phobos itself through 
 dub? Rust makes people use their build tool, why not us?


That's the day I stop using D.

I do not, and will not, use dub. Full stop.

Same goes for Rust ;-)
Mar 06 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 07/03/2018 2:54 PM, psychoticRabbit wrote:

 On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote:

 Also, if you'll allow me to have crazy ideas for a moment, one wonders 
 why we shouldn't just release Phobos itself through dub? Rust makes 
 people use their build tool, why not us?


 
 That's the day I stop using D.
 
 I do not, and will not, use dub. Full stop.
 
 Same goes for Rust ;-)


Under such arrangement nobody is forcing you to use dub.
We wouldn't break distribution or usage of dmd just because of changing 
a make file to dub. That's just silly.
Mar 06 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Mar 07, 2018 at 03:58:38PM +1300, rikki cattermole via
Digitalmars-d-announce wrote:

 On 07/03/2018 2:54 PM, psychoticRabbit wrote:

 On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote:

 
 Also, if you'll allow me to have crazy ideas for a moment, one
 wonders why we shouldn't just release Phobos itself through dub?
 Rust makes people use their build tool, why not us?


 
 That's the day I stop using D.
 
 I do not, and will not, use dub. Full stop.
 
 Same goes for Rust ;-)


 
 Under such arrangement nobody is forcing you to use dub.
 We wouldn't break distribution or usage of dmd just because of
 changing a make file to dub. That's just silly.


It will force everyone who compiles dmd from source to use dub. It's not
the end of the world, but I for one will not be too happy about it. Not
to mention, it will introduce bootstrapping issues to Phobos, since dub
itself depends on Phobos (again, solvable, but can be a potential source
of trouble).


T

-- 
Don't get stuck in a closet---wear yourself out.
Mar 07 2018
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 7 March 2018 at 14:20:54 UTC, H. S. Teoh wrote:


 It will force everyone who compiles dmd from source to use dub. 
 It's not the end of the world, but I for one will not be too 
 happy about it.


IMO, much better than forcing everyone to compile with make, 
which I'm not too happy about :-)
Mar 07 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Mar 07, 2018 at 02:53:17PM +0000, Mike Parker via
Digitalmars-d-announce wrote:

 On Wednesday, 7 March 2018 at 14:20:54 UTC, H. S. Teoh wrote:

 It will force everyone who compiles dmd from source to use dub. It's
 not the end of the world, but I for one will not be too happy about
 it.


 
 IMO, much better than forcing everyone to compile with make, which I'm
 not too happy about :-)



  parent  Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 3/7/18 12:02 PM, H. S. Teoh wrote:

 On Wed, Mar 07, 2018 at 02:53:17PM +0000, Mike Parker via
Digitalmars-d-announce wrote:

 On Wednesday, 7 March 2018 at 14:20:54 UTC, H. S. Teoh wrote:

 It will force everyone who compiles dmd from source to use dub. It's
 not the end of the world, but I for one will not be too happy about
 it.


 IMO, much better than forcing everyone to compile with make, which I'm
 not too happy about :-)


 
 Touché. :-D  The good thing is that make is pretty much guaranteed to
 exist in all OS installations (except Windows perhaps? But pretty much
 anywhere a compiler toolchain is installed), whereas dub isn't.


You need a D compiler to build D. So dub is probably there too.

Note that I'm against having phobos being a separate dependency from the 
compiler, but I'm not against switching to dub for the build.

-Steve



 Mar 07 2018



prev sibling  parent  Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 3/6/18 3:50 PM, Jack Stouffer wrote:

 On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:

 That being said, I'm wondering if it wouldn't be better to have 
 std.experimental be in its own repository. This allows selection of 
 the dependency on std.experimental separate from phobos. It still 
 would be an "official" dlang package, and might even be included in 
 the distribution (the latest version anyway), and docs included on the 
 website. But if needed, you could have your dub package depend on a 
 prior version.


 
 The entire concept needs a reexamination IMO. I just checked the git 
 history, and not one module has graduated from std.experimental to 
 mainline Phobos since the idea's inception in 2014. While it's possible 
 that none of the modules are ready, logger has been there for four years 
 now. I was against changing how experimental is handled in the past, but 
 I recently have started to rethink how we promote modules.


Promotion of modules is a different discussion. I think std.experimental 
is fine as a project, but just needs to be decoupled with needed 
compiler and stable library fixes.

To put it in terms of Atila's reference, it's like we coupled the 
breaking changes of boost-experimental with critical clang fixes.


 Also, if you'll allow me to have crazy ideas for a moment, one wonders 
 why we shouldn't just release Phobos itself through dub? Rust makes 
 people use their build tool, why not us?


No. Phobos has a reasonably stable API, and we need to keep it that way. 
There are too many coupled changes with Phobos and DMD that I think we 
would be asking for a mountain of "Why is this version of Phobos not 
compatible with this version of DMD?" bugs.

-Steve



 Mar 07 2018



prev sibling  parent  Random D user <no email.com>  writes:


On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote:

 I'd have a snowball's chance in hell convincing anyone at a 
 "regular" company of adopting D if anyone there even imagined 
 any of the above could happen.

 We have to do better than this.

 Atila


I don't think this is unusual even outside of D.
At least Microsoft seems to be willing to break your build if it 
moves things forward. For example, there are projects that worked 
fine on MSVC 15.4 (VS2017), but broke if you installed the update 
to 15.5 (or auto-updated in Visual Studio).
You can't test everything.

A lot of the "regular" companies, that desire high stability, 
typically use very old compilers and just workaround the bugs 
they know.
For a D example, I think Sociomantic was using D1 for a long time 
just because it was stable for them.

And if you need stability, why would you update the compiler 
without local testing and reserving time to fix any issues?



 Mar 06 2018



prev sibling  parent reply Martin Nowak <code dawg.eu>  writes:


On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote:

 Is is just me or did this release just break the latest 
 non-beta vibe.d? Is the Jenkins build testing the dub packages 
 on master instead of the latest tag?


Also this offer still stands
https://forum.dlang.org/post/drcekmxvfszpwifbukzk forum.dlang.org



 Mar 08 2018



  parent  Jacob Carlborg <doob me.com>  writes:


On 2018-03-08 19:21, Martin Nowak wrote:


 Also this offer still stands
 https://forum.dlang.org/post/drcekmxvfszpwifbukzk forum.dlang.org


Who will decide if semver can/will be used?

-- 
/Jacob Carlborg



 Mar 09 2018



prev sibling next sibling parent reply Chris M. <chrismohrfeld comcast.net>  writes:


On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:

 Glad to announce D 2.079.0.

 This release comes with experimental ` nogc` exception throwing 
 (-dip1008), a lazily initialized GC, better support for minimal 
 runtimes, and an experimental Windows toolchain based on the 
 lld linker and MinGW import libraries. See the changelog for 
 more details.

 Thanks to everyone involved in this 👏 
 https://dlang.org/changelog/2.079.0.html#contributors.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.079.0.html

 - -Martin


Good stuff. Still bothers me that we had to special case "throw 
new Exception();" in order to make it nogc. I can't think of any 
better ways right now, but I wish it was more explicit.



 Mar 05 2018



  parent  Martin Nowak <code dawg.eu>  writes:


On Monday, 5 March 2018 at 16:18:11 UTC, Chris M. wrote:

 Good stuff. Still bothers me that we had to special case "throw 
 new Exception();" in order to make it nogc. I can't think of 
 any better ways right now


Implementing EH for values (instead of class references) would 
have been a lot more complex.


 but I wish it was more explicit.


Initially people always want more explicitness for new, not yet 
too well known, features, while later opting for terser syntax 
for commonly used things.
Exceptions are supposed to be rare and deleting them directly 
after being catched seemed like a reasonable enough default to go 
with the specialization.
After all it solves a huge problem, error handling in  nogc code.
Maybe we'll find a better/cleaner solution when more of the 
language has been transitioned to  safe  nogc.



 Mar 06 2018



prev sibling  parent reply Void-995 <void995 gmail.com>  writes:


Can somebody explain how &array[0] is more safe than array.ptr? 
Just want to understand why second statement isn't allowed in 
safe anymore.



 Mar 05 2018



 next sibling parent reply psychoticRabbit <meagain meagain.com>  writes:


On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote:

 Can somebody explain how &array[0] is more safe than array.ptr? 
 Just want to understand why second statement isn't allowed in 
 safe anymore.



int[] a;
writeln(&arr[0]); // good - runtime produces a 
core.exception.RangeError
//writeln(arr.ptr); // what do you think will happen here?



 Mar 05 2018



  parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Tuesday, March 06, 2018 05:34:39 psychoticRabbit via Digitalmars-d-
announce wrote:

 On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote:

 Can somebody explain how &array[0] is more safe than array.ptr?
 Just want to understand why second statement isn't allowed in
 safe anymore.


 int[] a;
 writeln(&arr[0]); // good - runtime produces a
 core.exception.RangeError
 //writeln(arr.ptr); // what do you think will happen here?


That example actually should be perfectly  safe, because the array is null,
and it's using writeln. Dereferencing null is  safe, because it segfaults
and thus can't corrupt memory or access invalid memory. You obviously don't
want it to happen, but it's  safe. Also, passing a pointer to writeln is
fine, because it's just going to print the value, so that's  safe too, even
if the pointer value is garbage.

The problem is when the dynamic array's ptr points to something other than
null, and its length is 0. a[0] does bounds checking, so &a[0] is only valid
if the dynamic array's length is greater than 0, whereas a.ptr would happily
give you a value even if the array's length is 0, and in that case, it's not
valid to dereference that pointer. And depending on what that pointer points
to, it could corrupt memory or access invalid memory if you dereference it.

So, in _most_ cases, using ptr is actually fine, but because it's not
_always_  safe, the compiler has to treat it as  system. It was previously
thought to be fine, because the case where a dynamic array is empty but
non-null had not been considered when deciding whether ptr could be used in
 safe code.

- Jonathan m Davis



 Mar 05 2018



 next sibling parent  Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 3/6/18 2:11 AM, Jonathan M Davis wrote:

 On Tuesday, March 06, 2018 05:34:39 psychoticRabbit via Digitalmars-d-
 announce wrote:

 On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote:

 Can somebody explain how &array[0] is more safe than array.ptr?
 Just want to understand why second statement isn't allowed in
 safe anymore.


 int[] a;
 writeln(&arr[0]); // good - runtime produces a
 core.exception.RangeError
 //writeln(arr.ptr); // what do you think will happen here?


 
 That example actually should be perfectly  safe, because the array is null,
 and it's using writeln. Dereferencing null is  safe, because it segfaults
 and thus can't corrupt memory or access invalid memory. You obviously don't
 want it to happen, but it's  safe. Also, passing a pointer to writeln is
 fine, because it's just going to print the value, so that's  safe too, even
 if the pointer value is garbage.


Yeah, a better example:

struct S
{
    size_t[1] x;
    int *bad;
}

void foo()  safe
{
    S s;
    auto arr = s.x[$ .. $];
    // int *p = &arr[0]; // would throw range error
    auto p = arr.ptr; // this now points at bad
    *p = 0xdeadbeef;
    *s.bad = 5; // oops
}

-Steve



 Mar 06 2018



prev sibling  parent reply psychoticRabbit <meagain meagain.com>  writes:


On Tuesday, 6 March 2018 at 07:11:24 UTC, Jonathan M Davis wrote:

 That example actually should be perfectly  safe, because the 
 array is null, and it's using writeln. Dereferencing null is 
  safe, because it segfaults and thus can't corrupt memory or 
 access invalid memory. You obviously don't want it to happen, 
 but it's  safe. Also, passing a pointer to writeln is fine, 
 because it's just going to print the value, so that's  safe 
 too, even if the pointer value is garbage.


my point had nothing to do with writeln.

my point was, that a RangeError exception may help save the day, 
but not when you use .ptr

thankfully Steven gave a much better example to make the point 
clearer ;-)

(I assume that int is meant to be size_t)



 Mar 06 2018



  parent  Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 3/6/18 11:13 AM, psychoticRabbit wrote:


 (I assume that int is meant to be size_t)


Yes, I changed the uncommented one to auto after I realized, but not the 
commented one ;)

-Steve



 Mar 06 2018



prev sibling  parent  Martin Nowak <code dawg.eu>  writes:


On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote:

 Can somebody explain how &array[0] is more safe than array.ptr? 
 Just want to understand why second statement isn't allowed in 
 safe anymore.


&array[0] is runtime bounds-checked
array.ptr is unchecked and might return an out-of-bounds pointer 
(to the first element)



 Mar 06 2018