LDC 1.2.0-beta2 has been released!

[Kai Nacke via Digitalmars-d-announce]

Hi everyone,

LDC 1.2.0-beta2, the LLVM-based D compiler, is available for 
download!
This BETA release is based on the 2.072.2 frontend and standard 
library and supports LLVM 3.5-4.0.


We provide binaries for Linux, OX X, FreeBSD, Win32 & Win64, now 
bundled with DUB. :-)


As usual, you can find links to the changelog and the binary 
packages over at digitalmars.D.ldc:

http://forum.dlang.org/post/faxnftxqelfawtuyr...@forum.dlang.org

Regards,
Kai

Re: Proposal: Exceptions and @nogc

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/04/2017 04:08 AM, Atila Neves wrote:


I think the point here is that some people already use pre-allocated
exceptions. With this proposal, they'd have to change their codebase or
suddenly have it go much slower.



Isn't the main point of pre-allocated exceptions to improve 
control/determinism in memory usage/allocation?


I don't think speed is the issue. As I see it, the issue is that it 
takes "this throw was SPECIFICALLY DESIGNED to NOT affect the heap" and 
turns it into "this throw DOES affect the heap, even though the author 
went out of their way to deliberately prevent that".

Re: shared: Has anyone used it without a lot of pain?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, April 04, 2017 21:56:37 Atila Neves via Digitalmars-d wrote:
> I feel dirty if I write `__gshared`. I sneeze when I read it.

Well, it was designed with C global variables in mind, and it's pretty risky
to use it for anything else, though you can get away with it if you're
careful. However, I'm inclined to argue that __gshared really shouldn't ever
be used on anything that's extern(D). The problem of course is that shared
is a bit of a pain to use. Some of those pain points make sense even if
they're annoying and some of them should probably be fixed.

> But everytime I try and use `shared` I get trouble for it.

Yeah. It works, but it is annoying to use.

> The reason why what I was trying to do isn't possible is obvious
> in hindsight, but it's still annoying. So either code duplication
> or mixins, huh?

Unfortunately, the idea seems to be that any user-defined objects that are
marked as shared should have been designed to be shared and that a type
would normally either always be shared or never shared. On some level, that
makes sense, but it can also be really annoying, because sometimes, it
really does make sense to use the same type in both shared and un-shared
contexts. But the reality of the matter is that anything that isn't really
basic is going to tend to have to either always be shared or never shared.
The destructor case does seem like it should be fixed though.

- Jonathan M Davis

shared: Has anyone used it without a lot of pain?

[Atila Neves via Digitalmars-d]

I feel dirty if I write `__gshared`. I sneeze when I read it. But 
everytime I try and use `shared` I get trouble for it.


TIL that if I want a struct to be both `shared` and not, 
destructors are out of the way. Because while constructors are 
easy because we can have more than one:


struct Foo {
this(this T)() { }
}

auto f1 = const Foo();
auto f2 = shared Foo();

There can be only one destructor:


struct Bar {
this(this T)() { }
~this() {} // no shared, if there was the problem would 
reverse

// ~this(this T)() {} isn't a thing
}

auto b1 = const Bar();
// Error: non-shared method foo.Bar.~this is not callable using a 
shared object

// auto b2 = shared Bar(); //oops

The reason why what I was trying to do isn't possible is obvious 
in hindsight, but it's still annoying. So either code duplication 
or mixins, huh?


Atila

Re: Using Hashtags with posts

[Jonathan M Davis via Digitalmars-d]

On Tuesday, April 04, 2017 16:42:53 Binarydepth via Digitalmars-d wrote:
> So I've been a member of Ask Ubuntu at Stack Exchange for a while
> now. I saw the tags could be useful here:
>
> Someone could search Metaprogramming, OOP, Imperative, Data type,
> Arrays and find something inside the DLearn section. That could
> work along with a post tutorial session.

This "forum" is actually newsgroup that can be accessed as a newsgroup, via
a mailing list, or via the web interface. As such, while some stuff could be
added to the web interface, most things would not play well with the fact
that it's backed by a newsgroup. Certainly, tagging posts wouldn't work for
anyone who wasn't accessing the newsgroup via the web interface. No one else
would see the tags, and no posts by anyone accessing the newsgroup as a
newsgroup or as a mailing list would have any tags.

- Jonathan M Davis

Re: Proposal: Exceptions and @nogc

[Walter Bright via Digitalmars-d]

On 4/4/2017 10:38 AM, Atila Neves wrote:

Right, but that doesn't mean the slow path should become all the more slower for
codebases that do this. I haven't, but if I had I'd imagine I'd be none too
happy about it.


A year ago or so, I switched the exception unwinding mechanism for D on Linux 
from our custom solution to the Elf method used by every other language on 
Linux. It's a lot slower now - but it's compatible :-)


Copying a dozen bytes isn't going to make any measurable difference.

Re: cmake-d and gdc/gdmd compiler

[Dragos Carp via Digitalmars-d-learn]

On Tuesday, 4 April 2017 at 18:42:45 UTC, timvol wrote:

Hi guys,

I'm trying to cross-compile a project using CMake and gdc (or 
better: the gdmd port). My CMakeLists-file is the following:




For cross-compiling, CMake uses a so called "toolchain" file [1] 
where you define the system paths similar to the target system.


I confess that never cross-compiled any code with cmake-d, but in 
principle it should work.


Dragos

[1] 
https://cmake.org/cmake/help/v3.7/manual/cmake-toolchains.7.html#cross-compiling-for-linux

cmake-d and gdc/gdmd compiler

[timvol via Digitalmars-d-learn]

Hi guys,

I'm trying to cross-compile a project using CMake and gdc (or 
better: the gdmd port). My CMakeLists-file is the following:


cmake_minimum_required(VERSION 2.8.1)

set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} 
"${CMAKE_SOURCE_DIR}/cmake-d")

SET(CMAKE_SYSTEM_NAME Linux)

project(myapp D)
set(CMAKE_D_FLAGS "${CMAKE_D_FLAGS} ${GLOBAL_DMD_DEFS}")

set(SOURCES
main.d
generic.d
)

include_directories(.)

add_executable(myapp ${SOURCES})

I'm working on Windows and I want compile the project for the 
target linux system. So, I downloaded the gdc (x86_64-linux-gnu), 
extracted it and set the PATH variable. Unfortunately, when I 
configure my project using CMake, I'm getting the following 
message:


CMake Error at 
C:/Users/User/Desktop/Project/cmake-d/CMakeDetermineDCompiler.cmake:32 (MESSAGE):

  Could not find compiler set in environment variable C:

  CMAKE_D_COMPILER-NOTFOUND.
Call Stack (most recent call first):
  CMakeLists.txt:6 (project)


CMake Error: CMAKE_D_COMPILER not set, after EnableLanguage

I think CMake cannot find the compiler because the executables of 
gdc are named like "x86_64-unknown-linux-gnu-gdc". So, I've added 
the following to my CMakeLists-file:


set(CMAKE_D_COMPILER x86_64-unknown-linux-gnu-gdmd)

But this also fails with the following error:

The D compiler identification is GNU
Check for working D compiler: 
C:/Users/User/Compiler/x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu-gdmd.exe
Check for working D compiler: 
C:/Users/User/Compiler/x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu-gdmd.exe -- broken

To force a specific D compiler set the DC environment variable
ie - export DC="/usr/bin/dmd"
CMake Error at 
C:/Users/User/Desktop/cmake-d/CMakeTestDCompiler.cmake:45 
(message):

  The D compiler
  
"C:/Users/User/Compiler/x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu-gdmd.exe"

  is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: 
C:/Users/User/Desktop/Project.linux/CMakeFiles/CMakeTmp




  Run Build Command:"C:/Users/User/Compiler/ninja.exe"
  "cmTC_365e1"

  [1/2] Building D object CMakeFiles\cmTC_365e1.dir\testDCompiler


  FAILED: CMakeFiles/cmTC_365e1.dir/testDCompiler



  
C:\Users\User\Entwicklung\Compiler\x86_64-unknown-linux-gnu\bin\x86_64-unknown-linux-gnu-gdmd.exe

  CMakeFiles\cmTC_365e1.dir\testDCompiler -c
  
C:\Users\User\Desktop\Project.linux\CMakeFiles\3.7.2\CMakeTmp\testDCompiler.d




  x86_64-unknown-linux-gnu-gdc.exe: error:
  CMakeFiles\cmTC_365e1.dir\testDCompiler.d: No such file or 
directory





  x86_64-unknown-linux-gnu-gdc.exe: fatal error: no input files




  compilation terminated.




  Compile of ["CMakeFiles\\cmTC_365e1.dir\\testDCompiler.d"] 
failed




  ninja: build stopped: subcommand failed.






  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:7 (project)


Configuring incomplete, errors occurred!
See also 
"C:/Users/User/Desktop/Project.linux/CMakeFiles/CMakeOutput.log".


Does anyone know what can cause the problem here? I've also set 
the DC environment variable but I'm still getting the errors :(

Re: Proposal: Exceptions and @nogc

[Atila Neves via Digitalmars-d]

On Tuesday, 4 April 2017 at 08:41:51 UTC, Walter Bright wrote:

On 4/4/2017 1:08 AM, Atila Neves wrote:
I think the point here is that some people already use 
pre-allocated exceptions.
With this proposal, they'd have to change their codebase or 
suddenly have it go

much slower.


High performance code should never have exceptions in the fast 
path. The code gen is heavily and unapologetically biased 
towards speed in the non-exception path. This is true for C++ 
and D.


Right, but that doesn't mean the slow path should become all the 
more slower for codebases that do this. I haven't, but if I had 
I'd imagine I'd be none too happy about it.


Atila

Re: Deprecation of implicit string concatenation

[Jacob Carlborg via Digitalmars-d]

On 2017-04-02 16:20, Johan Engelen wrote:


I've been thinking for some time now about making a good code formatter,
and the removal of the automatic concat (and the necessity of parens)
makes automatic reformatting of code _a lot_ harder.


Assuming you're thinking of splitting up lines that are too long. In my 
opinion, splitting up string literals should only be chosen as one of 
the last resorts.


For example the Clang formatter, at least in the beginning, only 
modifies whitespace.


--
/Jacob Carlborg

Re: Interfacing D with C and Fortran

[data pulverizer via Digitalmars-d]

On Tuesday, 4 April 2017 at 16:20:56 UTC, bachmeier wrote:
Unless I missed it, there is no mention of iso_c_binding for 
Fortran. That is worth at least a mention, because


- It is documented well and handles many of the underlying 
details.
- It creates a C interface that can then be called from D like 
a C function.
- The target audience of this article includes C programmers 
already calling into Fortran using iso_c_binding. There's no 
reason for them to think they have to learn something new to 
switch to D.


I haven't used Fortran in some time, but when I did call it 
from C, iso_c_binding was very helpful.


Fair point. I was in two minds about mentioning this because 
Fortran programmers will already know about it but including it 
is probably the right thing.

Re: [OT] ISO C++ 17 changes

[H. S. Teoh via Digitalmars-d]

On Tue, Apr 04, 2017 at 01:38:32AM -0700, Walter Bright via Digitalmars-d wrote:
> On 4/3/2017 11:24 AM, Meta wrote:
> > I don't know how fold expressions could be emulated in D.
> 
> http://dlang.org/phobos/std_algorithm_iteration.html#.fold

That is not what "fold expressions" mean.  Fold expressions are
newly-introduced C++ syntax where you can write:

bool b = ... && args;

(with a literal "...") and the compiler automatically expands it to
`args[0] && args[1] && args[2]` (assuming args has 3 elements).

Of course, whether or not D ought to have such a thing is up for debate.
My present opinion is that D doesn't need it, because D's compile-time
capabilities are already convenient enough to use without needing
special syntax support from the language.


T

-- 
Customer support: the art of getting your clients to pay for your own 
incompetence.

Using Hashtags with posts

[Binarydepth via Digitalmars-d]

So I've been a member of Ask Ubuntu at Stack Exchange for a while 
now. I saw the tags could be useful here:


Someone could search Metaprogramming, OOP, Imperative, Data type, 
Arrays and find something inside the DLearn section. That could 
work along with a post tutorial session.

Re: Interfacing D with C and Fortran

[bachmeier via Digitalmars-d]

On Tuesday, 4 April 2017 at 13:25:27 UTC, data pulverizer wrote:

Hi All,

@9il and I have written a D blog article titled "Interfacing D 
with C and Fortran" which is located here: 
https://github.com/dataPulverizer/interface-d-c-fortran. We 
would greatly appreciate feedback from the D community before 
we publish it.


Many thanks in advance.

DP


Unless I missed it, there is no mention of iso_c_binding for 
Fortran. That is worth at least a mention, because


- It is documented well and handles many of the underlying 
details.
- It creates a C interface that can then be called from D like a 
C function.
- The target audience of this article includes C programmers 
already calling into Fortran using iso_c_binding. There's no 
reason for them to think they have to learn something new to 
switch to D.


I haven't used Fortran in some time, but when I did call it from 
C, iso_c_binding was very helpful.

[Issue 12331] Wrong error message for undefined identifier at compile-time

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12331

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #1 from Nick Treleaven  ---
DMD 2.073.2 gives:
f625.d(6): Error: circular initialization of variable 'f625.r'

foo is allowed to read global enum r, so this seems correct behaviour. What
else should be done?

--

Re: Interfacing D with C and Fortran

[data pulverizer via Digitalmars-d]

Thanks for the constructive feedback! Glad you liked the article.

On Tuesday, 4 April 2017 at 15:40:49 UTC, jmh530 wrote:


I liked it. Here are my thoughts:

In some cases, there were bits that I don't follow as well like 
where you have

$ nm example1.o
and its results


You're right some more explanation here would be useful

You might want to highlight that betterC is not well documented 
and provide a few more details on what it means, what are the 
limitations, etc.


True, there isn't a lot of material around about this flag and 
I'd appreciate some more details from those "in the know", @9il 
knows more about this than I do.


You wrote an apply function. Is phobos' map not compatible with 
betterC? Maybe mention that mir has a map function in ndslice 
algorithm that could be a betterC alternative.


@9il and I agreed that we would keep this article dependency free 
but we can include links to those alternatives.


You also discuss template alias parameters when talking about 
apply. Template aliases seem a bit like magic to me. Sure, I've 
used them, but still seem like magic. And I don't think the D 
docs do a great job explaining it. Maybe give a short 
explanation in addition to what is there (perhaps as a 
footnote?).


Wow a footnote! This might look like a real article :-) That was 
a joke! We can add a short description with links. I think a 
detailed article can be written on template alias parameters 
alone.


Thanks a lot for your feedback. It is much appreciated

Re: 'scope' finds stack corruption bug in druntime

[Steven Schveighoffer via Digitalmars-d]

On 4/4/17 6:19 AM, Walter Bright wrote:

On 4/4/2017 2:22 AM, Steven Schveighoffer wrote:

On Tuesday, 4 April 2017 at 08:32:33 UTC, Walter Bright wrote:

https://github.com/dlang/druntime/pull/1799

In complex code, it is impractical to check for this stuff manually.
I'm happy
that 'scope' is proving its worth.


Not a bug. Exception is allocated in the outer function and is always
caught in
the outer function. How can it escape?


You are correct, it is a false positive. I updated the PR with another
method, as doing the flow analysis to detect the false positive isn't
simple.



One thing to keep in mind, I'm probably not the only one to consider a 
pre-allocated scope exception for flow control on a very recursive 
algorithm using inner functions. If the scope changes are catching a 
false positive here, they will catch one in others' code as well. 
Especially people who want to write @nogc code.


The updates you have implemented are IMO much more complex than an 
"escape hatch" throwing of an exception to unwind the stack. Not 
horrific, but definitely more error prone and less intuitive.


-Steve

Re: [OT] ISO C++ 17 changes

[Russel Winder via Digitalmars-d]

On Tue, 2017-04-04 at 12:46 +, Xinok via Digitalmars-d wrote:
> On Tuesday, 4 April 2017 at 02:43:26 UTC, evilrat wrote:
> > String interpolation would be nice too, it would really help 
> > with readability!
> 
> This really isn't in the spirit of D and is better left to 
> library functions which give the user far more power and 
> flexibility. Incorporating such a feature into the language 
> raises many questions and concerns:

Interestingly, or not, Python 3.6 introduces string interpolation even
though Python already has the format function. And pythonistas are
happy about this.

> * It becomes a language feature thereby further bloating the 
> language and runtime
> * What if you want it to be @nogc?
> * What if you want to combine it with allocators?
> * What if you want to store the result in a particular buffer?
> * What if you want the result to be lazily evaluated?
> * What if you want an input range of chars? ... that is lazily 
> evaluated?
> * What if you want to format the arguments in a specific way?
> 
> Given the ease in which such a feature can be implemented and 
> used as a library function, I don't see interpolated strings as 
> being a necessary feature in D.
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: Interfacing D with C and Fortran

[jmh530 via Digitalmars-d]

On Tuesday, 4 April 2017 at 13:25:27 UTC, data pulverizer wrote:

Hi All,

@9il and I have written a D blog article titled "Interfacing D 
with C and Fortran" which is located here: 
https://github.com/dataPulverizer/interface-d-c-fortran. We 
would greatly appreciate feedback from the D community before 
we publish it.


Many thanks in advance.

DP


I liked it. Here are my thoughts:

In some cases, there were bits that I don't follow as well like 
where you have

$ nm example1.o
and its results

You might want to highlight that betterC is not well documented 
and provide a few more details on what it means, what are the 
limitations, etc.


You wrote an apply function. Is phobos' map not compatible with 
betterC? Maybe mention that mir has a map function in ndslice 
algorithm that could be a betterC alternative.


You also discuss template alias parameters when talking about 
apply. Template aliases seem a bit like magic to me. Sure, I've 
used them, but still seem like magic. And I don't think the D 
docs do a great job explaining it. Maybe give a short explanation 
in addition to what is there (perhaps as a footnote?).

Re: Proposal: Exceptions and @nogc

[Kagamin via Digitalmars-d]

On Monday, 3 April 2017 at 15:16:31 UTC, Jack Stouffer wrote:

On Monday, 3 April 2017 at 14:36:43 UTC, Kagamin wrote:

I suppose they link-hack GC, not druntime.


Nope, they get rid of everything, see 
https://theartofmachinery.com/2016/12/18/d_without_runtime.html


That article is pretty careful:

As an example
as if it were C code to begin with
Even then, there are useful compromises between the extremes of 
“no D runtime” and “full D runtime”.
Also see the next post 
https://theartofmachinery.com/2017/01/24/boot_to_d.html - not 
exactly GC purity.
Also the removed parts there are not runtime, but compiler 
generated stuff added to the object file that would need runtime, 
like reference to the personality function.

Re: Proposal: Exceptions and @nogc

[Jack Stouffer via Digitalmars-d]

On Tuesday, 4 April 2017 at 00:45:08 UTC, Moritz Maxeiner wrote:
AFAICT this solution will end up with everyone always calling 
theAllocator.dispose when catching from Phobos.


Yes, because you can no longer assume that the GC is being used, 
as all current Phobos code does.


Here's the thing, this problem misses the forrest for the trees. 
Focusing on exceptions is not seeing the broader problem of the 
user being at the mercy of Phobos devs with their choices of 
allocations. Exceptions are one aspect of the problem of 
allocation in a standard library with multiple allocation methods 
available. It's only as a matter of convenience that we've been 
using the GC for everything when stack allocation isn't enough. 
If we want to compete with Rust and C++* need a clean way to let 
the user control memory throughout their program.


As already pointed out, this is one ad-hoc solution to a specific 
problem rather than a holistic solution.



* to be honest, I would be fine if it was concluded that this 
isn't what we want to compete with. Java and C# didn't mostly 
replace C++ by being "C++ but slightly different". They won 
because they were something different that allowed you to get 
shit done. What does D want to be, a better C++ or a better 
language?


I don't think it's possible to have a clean language + std 
library and have the same amount of power as C++, the GC is just 
to convenient and takes off so much cognitive load. If we want to 
compete with C++ with Phobos, Phobos will need to become more 
ugly but more flexible.

Re: Testing D codes

[Kagamin via Digitalmars-d-learn]

Same as anywhere else. Integration test is a test that connects 
to a deployed system, which is different from unittest only in 
philosophical aspect.

Re: Exceptions in @nogc code

[deadalnix via Digitalmars-d]

On Tuesday, 4 April 2017 at 09:45:14 UTC, Walter Bright wrote:
1. we already have some of the benefits of the proposal because 
D has transitive immutability




This works hand in hand with D type qualifier system.

2. I'm looking for a solution where exceptions don't rely on 
the GC to the point where the GC code doesn't even need to be 
linked in. This proposal appears to maintain a dependence on 
the GC.




Then just do:
auto ePtr = malloc(...);
auto e = *(cast(Exception*) );
throw e;

Problem solved, you did not used the GC.

This proposal has nothing to do with Exceptions. It just happens 
to solve the Exception problem, just as it does for many others.


The problem people have with the GC isn't that it need to be 
linked in, it is that collection cycles create latency that 
doesn't work for their use case. If allocation are freed, then 
there is no GC problem.


Nobody is complaining that they cannot use C++ without its 
runtime. And for the 0.1% who actually need it, they just write 
custom allocation, and jump through a few hoops. This is a just 
good engineering. You are trying to solve the wrong problem.


really, in the process you are also murdering another legit use 
case that is orders of magnitude more common: library writers. 
They want to write code that'll work when the GC is used or not.


3. It requires annotation of catch declarations with one of "", 
"scope", or "owned". I expect this would be a significant 
problem




This proposal just add the owned type qualifier. scope already 
exists. It solves many problem for which new syntax have been 
introduced, so it's rather rich.


"I don't want this proposal that add one new syntax, I'd rather 
have 4 smaller proposals that each add a new syntax."


4. Since the catch block is not type checked against the 
corresponding throw, the object will have to have noted in it 
who owns it.




throw never leaks, so there is no point in checking the throw. 
You already throw something that is owned by the GC, in which 
case you leaked earlier, or you transfer the ownership to the 
runtime and you haven't leaked yet.


Because throw never leaks, there is no point in butchering throw 
to make it compatible with nogc.


Back to the catch block, the question is the same as for a 
function call or anything else really. It either borrow the 
exception (scope) take ownership of it (owned) or just delegate 
the work to the GC.



5. The normal case is:

throw new Exception("message");
...
catch (Exception e) {
 writeln(e.msg);
}

which would ideally work without involving the GC at all.



This cannot be nogc in the general case because e can be 
reassigned to anything that is owned by the GC. In that specific 
case, scope can be inferred.


6. reducing the amount of GC garbage created is good, but does 
not solve the problem of "I don't want to use D because of the 
GC".


This proposal looks promising for making a better garbage 
collected language, but people want a language with an optional 
GC.


If you have guarantee that you won't leak, and so will never run 
collection cycle, you don't have a GC, you effectively have 
malloc and free. There is no need to butcher the language because 
there are morons on the internet. really that's hardly newsworthy.

Re: Covert a complex C header to D

[Ali Çehreli via Digitalmars-d-learn]

On 04/02/2017 02:43 PM, biocyberman wrote:
> khash.h
> 
(http://attractivechaos.github.io/klib/#Khash%3A%20generic%20hash%20table)

> is a part of klib library in C. I want to covert it to D in the process
> of learning deeper about D.

These are macros used by the library developer to generate library 
facilities without repetition. Not uncommon for C libraries... As 
Nicholas Wilson says, just ignore most of these macros because in the 
end what you want are the types and functions that the public interface 
of the library includes. (Or, the public documentation of the library 
includes.)


In this case, looking at the preprocessor output to see what is 
generated may help. For example, use the -E compiler switch of gcc. If 
you're not familiar with this switch, you may be intimidated at first as 
it includes all headers that your header includes itself. Just search 
for the said library types and functions to see how they ended up like 
after preprocessing.


Ali

Re: [OT] ISO C++ 17 changes

[ag0aep6g via Digitalmars-d]

On 04/04/2017 03:45 PM, Meta wrote:

I mean what goes on inside fold.


Ok. That's what I missed.


If you look at the C++ example it's
very concise and IMO beautiful:

 auto f(Args ...args) { return (0 + ... + args); }


But the shown `fold` implements the functionality of that C++ language 
feature. That is, you have to compare `fold!"+"(args)` with `(0 + ... + 
args)`. The C++ version may be more beautiful, but verbosity seems about 
the same.


I think I accidentally sent this directly to your email, too. Sorry 
about that; Thunderbird's "answer" buttons can be confusing for me.

Re: [OT] ISO C++ 17 changes

[Dukc via Digitalmars-d]

On Tuesday, 4 April 2017 at 13:45:47 UTC, Meta wrote:
I mean what goes on inside fold. If you look at the C++ example 
it's very concise and IMO beautiful:


Luckily that hardly matters, you just need to define one generic 
template for the whole program, which can even be in a library.


Btw my fold template implementation was erroneous, I forgot to 
mixin the operator string passed to it.

Re: [OT] ISO C++ 17 changes

[Meta via Digitalmars-d]

On Tuesday, 4 April 2017 at 13:38:57 UTC, ag0aep6g wrote:

On 04/04/2017 03:29 PM, Meta wrote:

On Tuesday, 4 April 2017 at 05:04:04 UTC, Dukc wrote:

[...]

fold!"+"(1, 2, 3).writeln; //6

[...]
However, it's still more verbose. My goal was to emulate 
almost exactly

what C++ was doing by using a template so you could just write
"fold!('+', args)"


I'm probably missing something, but `fold!"+"(args)` isn't more 
verbose than `fold!('+', args)`.


I mean what goes on inside fold. If you look at the C++ example 
it's very concise and IMO beautiful:


 auto f(Args ...args) { return (0 + ... + 
args); }


So I wanted a solution that was about the same in terms of 
brevity. My first attempt was:


enum fold(string op, Args...) = mixin("Args[0] " ~ op ~ " 
fold!(op, Args[1..$])";


But of course this doesn't work.

Re: [OT] ISO C++ 17 changes

[ag0aep6g via Digitalmars-d]

On 04/04/2017 03:29 PM, Meta wrote:

On Tuesday, 4 April 2017 at 05:04:04 UTC, Dukc wrote:

[...]

fold!"+"(1, 2, 3).writeln; //6

[...]

However, it's still more verbose. My goal was to emulate almost exactly
what C++ was doing by using a template so you could just write
"fold!('+', args)"


I'm probably missing something, but `fold!"+"(args)` isn't more verbose 
than `fold!('+', args)`.

Re: [OT] ISO C++ 17 changes

[Meta via Digitalmars-d]

On Tuesday, 4 April 2017 at 08:38:32 UTC, Walter Bright wrote:

On 4/3/2017 11:24 AM, Meta wrote:

I don't know how fold expressions could be emulated in D.


http://dlang.org/phobos/std_algorithm_iteration.html#.fold


Not quite the same as this is a fold over a TypeTuple/AliasSeq. 
You could of course do:


only(args).fold!"a + b"()

But the semantics are different.

Re: [OT] ISO C++ 17 changes

[Meta via Digitalmars-d]

On Tuesday, 4 April 2017 at 05:04:04 UTC, Dukc wrote:

On Monday, 3 April 2017 at 21:43:41 UTC, Meta wrote:

On Monday, 3 April 2017 at 21:33:20 UTC, Timon Gehr wrote:
Any suggestions as to how to get something similar working?


auto fold(string op, Args...)(Args args)
{
foreach(e; args[1 .. $]) args[0] += e;
return args[0];
}

void main()
{
import std.stdio;
fold!"+"(1, 2, 3).writeln; //6
}


This does work I guess. I'm not sure if the foreach will be 
unrolled or not but if it is I guess this is fairly close to the 
C++ example. However, it's still more verbose. My goal was to 
emulate almost exactly what C++ was doing by using a template so 
you could just write "fold!('+', args)" and have it automatically 
rewritten as "Args[0] + Args[1] + Args[2] ...". However it gets 
difficult because the compiler is trying to interpret args at 
compile time.

Interfacing D with C and Fortran

[data pulverizer via Digitalmars-d]

Hi All,

@9il and I have written a D blog article titled "Interfacing D 
with C and Fortran" which is located here: 
https://github.com/dataPulverizer/interface-d-c-fortran. We would 
greatly appreciate feedback from the D community before we 
publish it.


Many thanks in advance.

DP

Testing D codes

[Russel Winder via Digitalmars-d-learn]

Are there any resources dealing with how to do integration and system
testing of D codes? Google invariably just leads me to unit testing.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: [OT] ISO C++ 17 changes

[Xinok via Digitalmars-d]

On Tuesday, 4 April 2017 at 02:43:26 UTC, evilrat wrote:
String interpolation would be nice too, it would really help 
with readability!


This really isn't in the spirit of D and is better left to 
library functions which give the user far more power and 
flexibility. Incorporating such a feature into the language 
raises many questions and concerns:


* It becomes a language feature thereby further bloating the 
language and runtime

* What if you want it to be @nogc?
* What if you want to combine it with allocators?
* What if you want to store the result in a particular buffer?
* What if you want the result to be lazily evaluated?
* What if you want an input range of chars? ... that is lazily 
evaluated?

* What if you want to format the arguments in a specific way?

Given the ease in which such a feature can be implemented and 
used as a library function, I don't see interpolated strings as 
being a necessary feature in D.

Re: pImpl in D

[Dejan Lekic via Digitalmars-d]

On Tuesday, 4 April 2017 at 12:05:15 UTC, Satoshi wrote:

Hi,
do someone have any experience with pImpl and inheritance in D?


Some parts of Phobos use it. Example: 
https://github.com/dlang/phobos/blob/master/std/stdio.d

Have a look at the struct ByLine

It has something like:

struct ByLine(Char, Terminator)
{
private:
import std.typecons : RefCounted, 
RefCountedAutoInitialize;


/* Ref-counting stops the source range's Impl
 * from getting out of sync after the range is copied, 
e.g.

 * when accessing range.front, then using std.range.take,
 * then accessing range.front again. */
alias PImpl = RefCounted!(Impl, 
RefCountedAutoInitialize.no);

PImpl impl;

Re: pImpl in D

[Satoshi via Digitalmars-d]

test/Foo.di(3,1): Error: class test.Foo.FooPrivate is forward 
referenced when looking for 'opAssign'


forward reference in Foo.di


test/Bar.d(14,25): Error: cannot implicitly convert expression 
(p) of type test.BarPrivate.BarPrivate to test.Foo.FooPrivate


I'm unable to cast from BarPrivate to FooPrivate because it can't 
recognize Bar : Foo; inheritance from Foo.di (FooPrivate.d and 
BarPrivate.d is ignored).



test/Foo.di(3,1): Error: class test.Foo.FooPrivate is forward 
referenced when looking for 'opCast'


same as first

pImpl in D

[Satoshi via Digitalmars-d]

Hi,
do someone have any experience with pImpl and inheritance in D?

I tried something like:

// FooPrivate.d
class FooPrivate {
int a;
}


// BarPrivate.d
import FooPivate;

class BarPrivate : FooPrivate {
string b;
}


// Foo.d
import FooPrivate;

class Foo {
protected FooPrivate m_private;

this() { m_private = new FooPrivate; }
}


// Bar.d
import Foo;
import FooPrivate;
import BarPrivate;

class Bar : Foo {
this() { m_private = new BarPrivate; }
}


And public interface
// Foo.di
class FooPrivate;
class Foo {
private FooPrivate m_private;
}


Bar.d looks like it imported Foo with forward referenced 
FooPrivate and is unable to resolve it by importing FooPrivate.


Is this bug?
Do you know about any *less verbose* design pattern how I can 
hide implementaion details from .di files?


Thanks!

Re: Exceptions in @nogc code

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 4 April 2017 at 09:45:14 UTC, Walter Bright wrote:
6. reducing the amount of GC garbage created is good, but does 
not solve the problem of "I don't want to use D because of the 
GC".


I betcha D would be a better language with more users if you just 
told those people "sorry, it isn't for you then" and focused on 
improving what we already have.


I've never had a problem using D without a GC as it is now BTW. 
But that's because I'm more interested in getting work done than 
in endlessly whining about a language I don't even actually use 
or understand in Reddit comments.

Re: OT: It is convert, not covert

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 4 April 2017 at 09:37:12 UTC, biocyberman wrote:

On Tuesday, 4 April 2017 at 05:29:42 UTC, Ali Çehreli wrote:

Covert has a very different meaning. :)

Ali


Thanks Ali. My fingers argued they are the same :) And I can't 
find a way to edit my post after posting.


I would love to have your input. I am revisited your  book 
several times to read relevant sections. But these complex 
macros are still holding me back.


Most of those macros are not needed and can be just part the 
struct definition:


i.e. you want something like

struct kh_hashtable(K,V,bool _is_map, alias hash_func, alias 
hash_eq = (K a, K b)=> a == b) {

khint_t n_buckets, size, n_occupied, upper_bound;
khint32_t *flags;
 K *keys;
 V *vals;
//No need for __KHASH_PROTOTYPES / __KHASH_IMPL just declare 
the function as methods of the struct

this() { ... } // in place of kh_init_##name
~this() { ... } // for destroy
resize(khint_t new_size){ ... }  //kh_resize_##name
// and so on for each method in __KHASH_IMPL

}

Re: [OT] ISO C++ 17 changes

[evilrat via Digitalmars-d]

On Tuesday, 4 April 2017 at 10:40:19 UTC, Guillaume Piolat wrote:

On Tuesday, 4 April 2017 at 08:16:48 UTC, evilrat wrote:


Well, thanks, I guess... But it seems no one else interested 
in such feature. I get it.
Sure this shouldn't be top priority thing and it can(it surely 
will) be hard to implement in compiler, and this maybe not an 
option for such a little benefit, but at least I can dream one 
day it will made it in D, yay.


There is a library solution in scriptlike: 
https://p0nce.github.io/d-idioms/#String-interpolation-as-a-library


I think you only ever miss it when doing web stuff.


Сool, i was thinking about the same, just make interp with alias 
and mixin... But this lib has some other interesting functions 
too! Though not in Phobos, but at least dub makes it super quick 
to use. Thanks!


No, not web stuff, just quick dirty concepting stuff. 
Unfortunatelly this days I usually deal with C++ only :/

Re: Write file at compile time?

[Stefan Koch via Digitalmars-d-learn]

On Monday, 3 April 2017 at 21:20:41 UTC, Inquie wrote:

On Monday, 3 April 2017 at 19:34:36 UTC, Adam D. Ruppe wrote:

[...]


Because it the code doesn't compile one has to copy and paste 
the pragma output to a d file and compile it to find the 
errors. It is useful to help debug mixins. Since D is pretty 
sorry at giving useful information for mixins it is easier to 
write the mixins out to disk in a d file then input them back 
in to the program. A simple static switch can alternate between 
the two. If we could output at compile time then we could


[...]


If you're fine with a custom dmd build, please open an issue on 
my dmd repo.

[Issue 16630] Compile errors with std.traits.arity and std.traits.ParameterStorageClassTuple

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16630

Lucia Cojocaru  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WORKSFORME

--

[Issue 16630] Compile errors with std.traits.arity and std.traits.ParameterStorageClassTuple

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16630

--- Comment #1 from Lucia Cojocaru  ---
I've justed tested the given example with the current version (on master
branch) of dmd/druntime/phobos and there are no compilation errors. Compilation
was done on Linux 64bit, just as the bug indicates.

I will close this issue for the time being. If anybody is able to reproduce
this, please reopen it.

--

Re: [OT] ISO C++ 17 changes

[Guillaume Piolat via Digitalmars-d]

On Tuesday, 4 April 2017 at 08:16:48 UTC, evilrat wrote:


Well, thanks, I guess... But it seems no one else interested in 
such feature. I get it.
Sure this shouldn't be top priority thing and it can(it surely 
will) be hard to implement in compiler, and this maybe not an 
option for such a little benefit, but at least I can dream one 
day it will made it in D, yay.


There is a library solution in scriptlike: 
https://p0nce.github.io/d-idioms/#String-interpolation-as-a-library


I think you only ever miss it when doing web stuff.

Re: 'scope' finds stack corruption bug in druntime

[Walter Bright via Digitalmars-d]

On 4/4/2017 2:22 AM, Steven Schveighoffer wrote:

On Tuesday, 4 April 2017 at 08:32:33 UTC, Walter Bright wrote:

https://github.com/dlang/druntime/pull/1799

In complex code, it is impractical to check for this stuff manually. I'm happy
that 'scope' is proving its worth.


Not a bug. Exception is allocated in the outer function and is always caught in
the outer function. How can it escape?


You are correct, it is a false positive. I updated the PR with another method, 
as doing the flow analysis to detect the false positive isn't simple.

Re: Mike Parker is the new DIP czar

[Mike Parker via Digitalmars-d-announce]

Thanks!

Re: Exceptions in @nogc code

[Guillaume Piolat via Digitalmars-d]

On Monday, 3 April 2017 at 21:28:39 UTC, Andrei Alexandrescu 
wrote:


Got it. Could you please create an issue about this? -- Andrei


Sure.
https://issues.dlang.org/show_bug.cgi?id=17297

[Issue 17297] New: Object.~this not being @nogc is severely limiting @nogc applicability

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17297

  Issue ID: 17297
   Summary: Object.~this not being @nogc is severely limiting
@nogc applicability
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: alil...@gmail.com

destroy() infers it's "@nogc"-ness from rt_finalize which is not nothrow
and not @nogc:
https://github.com/dlang/druntime/blob/5a94816c8f1d5c225e560151cebe0a09949896a5/src/object.d#L16


I guess the rationale is that rt_finalize call Object.~this() and that
may GC allocate, and throw.

In turn this cause every wrapper using emplace+destroy to not be @nogc.

Current programs which run without the runtime must currently break the type
system in order to call destroy() anyway.

https://www.auburnsounds.com/blog/2016-11-10_Running-D-without-its-runtime.html

--

Re: Exceptions in @nogc code

[Walter Bright via Digitalmars-d]

Thank you for posting this.

Figuring all this out thoroughly will take some time, so this is just first 
impressions.


1. we already have some of the benefits of the proposal because D has transitive 
immutability


2. I'm looking for a solution where exceptions don't rely on the GC to the point 
where the GC code doesn't even need to be linked in. This proposal appears to 
maintain a dependence on the GC.


3. It requires annotation of catch declarations with one of "", "scope", or 
"owned". I expect this would be a significant problem


4. Since the catch block is not type checked against the corresponding throw, 
the object will have to have noted in it who owns it.


5. The normal case is:

throw new Exception("message");
...
catch (Exception e) {
 writeln(e.msg);
}

which would ideally work without involving the GC at all.

6. reducing the amount of GC garbage created is good, but does not solve the 
problem of "I don't want to use D because of the GC".


This proposal looks promising for making a better garbage collected language, 
but people want a language with an optional GC.

Re: OT: It is convert, not covert

[biocyberman via Digitalmars-d-learn]

On Tuesday, 4 April 2017 at 05:29:42 UTC, Ali Çehreli wrote:

Covert has a very different meaning. :)

Ali


Thanks Ali. My fingers argued they are the same :) And I can't 
find a way to edit my post after posting.


I would love to have your input. I am revisited your  book 
several times to read relevant sections. But these complex macros 
are still holding me back.

Re: 'scope' finds stack corruption bug in druntime

[Steven Schveighoffer via Digitalmars-d]

On Tuesday, 4 April 2017 at 08:32:33 UTC, Walter Bright wrote:

https://github.com/dlang/druntime/pull/1799

In complex code, it is impractical to check for this stuff 
manually. I'm happy that 'scope' is proving its worth.


Not a bug. Exception is allocated in the outer function and is 
always caught in the outer function. How can it escape?


-Steve

Re: Proposal: Exceptions and @nogc

[Walter Bright via Digitalmars-d]

On 4/3/2017 11:59 PM, Jonathan M Davis via Digitalmars-d wrote:

No, it's not a problem that's specific to exceptions, but the string for an
exception message is pretty critical and is going to have a significant
impact on the ability to use @nogc with exceptions. Just being able to have
the exception itself be allocated and managed safely via @nogc is definitely
a step up, but if we don't have a reasonable way to manage the exception's
message in @nogc code, then in many cases, we have a serious problem with
how informative exceptions are. And if you really don't care about the
exception message saying anything more than you can put in a string literal,
you can always pre-allocate the excetion and avoid the whole @nogc problem
that way without any of the proposed language changes. As such, I'm inclined
to think that the benefits of the proposed changes are minimal if they don't
fix the problem with the exception's message being GC-allocated.


https://github.com/dlang/druntime/blob/master/src/object.d#L1701

Re: Mike Parker is the new DIP czar

[Faux Amis via Digitalmars-d-announce]

On 2017-04-04 01:28, Andrei Alexandrescu wrote:

Hello,


By this we are happy to announce that Mike Parker graciously agreed to
take over the role of DIP czar.


Is this the list of all current ruling czars?
https://wiki.dlang.org/People

Maybe it should be accompanied with open positions.



DIP management requires a mix of skills (technical, editorial,
organizational, interpersonal, and literary) that Mike possesses in
spades. Looking forward to a long and fruitful cooperation.

Please join me in thanking and congratulating Mike!


Andrei


Congratulations Mike! ;)

Re: Proposal: Exceptions and @nogc

[Walter Bright via Digitalmars-d]

On 4/4/2017 1:08 AM, Atila Neves wrote:

I think the point here is that some people already use pre-allocated exceptions.
With this proposal, they'd have to change their codebase or suddenly have it go
much slower.


High performance code should never have exceptions in the fast path. The code 
gen is heavily and unapologetically biased towards speed in the non-exception 
path. This is true for C++ and D.

Re: [OT] ISO C++ 17 changes

[Walter Bright via Digitalmars-d]

On 4/3/2017 11:24 AM, Meta wrote:

I don't know how fold expressions could be emulated in D.


http://dlang.org/phobos/std_algorithm_iteration.html#.fold

'scope' finds stack corruption bug in druntime

[Walter Bright via Digitalmars-d]

https://github.com/dlang/druntime/pull/1799

In complex code, it is impractical to check for this stuff manually. I'm happy 
that 'scope' is proving its worth.

Re: [OT] ISO C++ 17 changes

[evilrat via Digitalmars-d]

On Tuesday, 4 April 2017 at 07:21:09 UTC, Andrea Fontana wrote:

On Tuesday, 4 April 2017 at 06:13:24 UTC, evilrat wrote:
On Tuesday, 4 April 2017 at 05:53:00 UTC, Patrick Schluter 
wrote:

On Tuesday, 4 April 2017 at 05:36:55 UTC, evilrat wrote:

On Tuesday, 4 April 2017 at 05:18:26 UTC, Dukc wrote:

On Tuesday, 4 April 2017 at 02:43:26 UTC, evilrat wrote:

[...]




writeln("Your item: ", someName, " = ", someInt");




This works due to variadic args nature of writeln, but the 
point is that it might be used with simple string assignment 
and other functions that takes one string, besides, the point 
is to avoid clutter and improve readability of code.


text("Your item: ", someName, " = ", someInt");


Well, thanks, I guess... But it seems no one else interested in 
such feature. I get it.
Sure this shouldn't be top priority thing and it can(it surely 
will) be hard to implement in compiler, and this maybe not an 
option for such a little benefit, but at least I can dream one 
day it will made it in D, yay.

Re: Proposal: Exceptions and @nogc

[Atila Neves via Digitalmars-d]

On Sunday, 2 April 2017 at 20:35:27 UTC, Walter Bright wrote:

On 4/2/2017 8:24 AM, Dmitry Olshansky wrote:

[...]


That's right.



[...]


Yes, it's possible. But I'd have to be convinced that there 
isn't some other problem with a design that requires 
preallocated exceptions.


[...]


I think the point here is that some people already use 
pre-allocated exceptions. With this proposal, they'd have to 
change their codebase or suddenly have it go much slower.


Atila

DConf 2017 lightning talks - how to apply?

[Atila Neves via Digitalmars-d]

Last year I missed the boat and ended up writing mine an hour 
before presenting it!


Atila

Re: [OT] ISO C++ 17 changes

[Andrea Fontana via Digitalmars-d]

On Tuesday, 4 April 2017 at 06:13:24 UTC, evilrat wrote:
On Tuesday, 4 April 2017 at 05:53:00 UTC, Patrick Schluter 
wrote:

On Tuesday, 4 April 2017 at 05:36:55 UTC, evilrat wrote:

On Tuesday, 4 April 2017 at 05:18:26 UTC, Dukc wrote:

On Tuesday, 4 April 2017 at 02:43:26 UTC, evilrat wrote:

[...]




writeln("Your item: ", someName, " = ", someInt");




This works due to variadic args nature of writeln, but the 
point is that it might be used with simple string assignment 
and other functions that takes one string, besides, the point 
is to avoid clutter and improve readability of code.


text("Your item: ", someName, " = ", someInt");

Re: opDispatch/template get this

[John Chapman via Digitalmars-d-learn]

On Monday, 3 April 2017 at 21:49:07 UTC, Inquie wrote:

I am using opDispatch to wrap function calls

Error: 'this' is only defined in non-static member functions, 
not opDispatch!"foo"


class X
{
auto localfoo() { return 3; }
template opDispatch(string name, Args...)
{
static if (name == `foo`) { alias opDispatch = () { 
return this.localfoo();

};
}


which doesn't work because of this

I tried

template opDispatch(string name, this _this, Args...)
{
	static if (name == `foo`) { alias opDispatch = () { return 
_this.localfoo(); };

}

but that doesn't work either ;/

I call it like

auto y = x.foo();

but foo isn't found


https://dpaste.dzfl.pl/bf31f535340f



class X
{
auto localfoo() { return 3; }
auto localfoo2(int x) { return x; }
template opDispatch(string name, Args...)
{
static if (name == `foo`)
{
alias opDispatch = () { return this.localfoo(); };
}
static if (name == `bar`)
{
			alias opDispatch = () { return this.localfoo2(); }; // need 
to be able to pass Args properly here

}
}
}

void main()
{
auto x = new X();
auto z = x.localfoo();
auto y = x.foo();
auto q = x.bar();
}


Make opDispatch a templated function and forward with 
__traits(getMember, this, "foo") or a mixin.


class X {

  auto localfoo() { return 3; }
  auto localfoo2(int x) { return x; }

  auto opDispatch(string name, Args...)(auto ref Args args) {
static if (name == "foo") return __traits(getMember, this, 
"localfoo")(args);
else static if (name == "bar") mixin("return 
localfoo2(args);");

  }

}

Re: Proposal: Exceptions and @nogc

[Jonathan M Davis via Digitalmars-d]

On Monday, April 03, 2017 15:20:23 Walter Bright via Digitalmars-d wrote:
> On 4/3/2017 2:31 PM, Jonathan M Davis via Digitalmars-d wrote:
> > Yeah, the simple fact that you can't allocate exceptions in @nogc code
> > is
> > crippling to @nogc, and a lot of code that could otherwise be @nogc
> > can't be because of exceptions - though the exception message poses a
> > similar problem (especially if you'd normally construct it with
> > format), and I don't know how you get around that other than not using
> > anything more informative than string literals. Unless I missed
> > something, this proposal seems to ignore that particular issue.
>
> You're right that this proposal does not address how memory is allocated
> for anything indirectly referenced by the exception object. That is an
> independent issue, and is not peculiar to exception objects.

No, it's not a problem that's specific to exceptions, but the string for an
exception message is pretty critical and is going to have a significant
impact on the ability to use @nogc with exceptions. Just being able to have
the exception itself be allocated and managed safely via @nogc is definitely
a step up, but if we don't have a reasonable way to manage the exception's
message in @nogc code, then in many cases, we have a serious problem with
how informative exceptions are. And if you really don't care about the
exception message saying anything more than you can put in a string literal,
you can always pre-allocate the excetion and avoid the whole @nogc problem
that way without any of the proposed language changes. As such, I'm inclined
to think that the benefits of the proposed changes are minimal if they don't
fix the problem with the exception's message being GC-allocated.

- Jonathan M Davis

Re: Proposal: Exceptions and @nogc

[Johannes Pfau via Digitalmars-d]

Am Mon, 03 Apr 2017 14:31:39 -0700
schrieb Jonathan M Davis via Digitalmars-d
:

> On Monday, April 03, 2017 14:00:53 Walter Bright via Digitalmars-d
> wrote:
> > The idea of this proposal is to make a nogc program much more
> > achievable. Currently, in order to not link with the GC, you can't
> > use exceptions (or at least not in a memory safe manner). A
> > solution without memory safety is not acceptable.  
> 
> Yeah, the simple fact that you can't allocate exceptions in @nogc
> code is crippling to @nogc, and a lot of code that could otherwise be
> @nogc can't be because of exceptions - though the exception message
> poses a similar problem (especially if you'd normally construct it
> with format), and I don't know how you get around that other than not
> using anything more informative than string literals. Unless I missed
> something, this proposal seems to ignore that particular issue.
> 
> - Jonathan M Davis
> 

Allocate the string using an Allocator, free in the Exceptions ~this?

This has to be integrated somehow with the copying scheme though, so
you'll probably need some kind of reference counting for classes
again or duplicate the string on every copy. 

-- Johannes

Re: [OT] ISO C++ 17 changes

[evilrat via Digitalmars-d]

On Tuesday, 4 April 2017 at 05:53:00 UTC, Patrick Schluter wrote:

On Tuesday, 4 April 2017 at 05:36:55 UTC, evilrat wrote:

On Tuesday, 4 April 2017 at 05:18:26 UTC, Dukc wrote:

On Tuesday, 4 April 2017 at 02:43:26 UTC, evilrat wrote:

[...]




writeln("Your item: ", someName, " = ", someInt");




This works due to variadic args nature of writeln, but the point 
is that it might be used with simple string assignment and other 
functions that takes one string, besides, the point is to avoid 
clutter and improve readability of code.