Re: DUB: "Invalid source/import path"

[Manuel Maier via Digitalmars-d-dwt]

On Monday, 15 May 2017 at 06:24:12 UTC, Ivan Trombley wrote:

Never mind. Figured it out.


It would be nice to know what it was that you figured out. I just 
ran into the same issue building gdub 
(https://github.com/jasc2v8/gdub).


Invalid source/import path: 
C:\Users\mjmai\AppData\Roaming\dub\packages\dwtlib-3.1.1\dwtlib\dwt\src
Invalid source/import path: 
C:\Users\mjmai\AppData\Roaming\dub\packages\dwtlib-3.1.1\dwtlib\dwt\views


Indeed, these paths do not exist. The question is why?

Re: Precise GC state

[Ola Fosheim Grostad via Digitalmars-d]

On Monday, 27 November 2017 at 06:59:30 UTC, Petar Kirov 
[ZombineDev] wrote:
the shared_ptr itself) and you can't opt out of that even if 
you're not sharing the shared_ptr with other threads.


Well, the compiler can in theory ellide atomics if it csn prove 
that the memory cannot be accessed by another thread.


But it kinda is missing the point that if it only is in a single 
thread then it would typically only have only one assignment. 
Shared_ptr is for holding a resource not for using it...

Re: Looking for a job in USA

[Walter Bright via Digitalmars-d]

On 11/26/2017 10:15 PM, Satoshi wrote:
Thanks everyone for your advices and helping me with finding job in the US. I 
applied for about 300 jobs at companies like Apple, M$, Amazon, Google, etc. and 
got one offer in Canada, so it's half-win for me. :)


Good luck!



BTW: Walter, why you don't use IP Board instead of this, custom made forum?


Because our forum here is better and faster than any of the various forum 
software we looked at. It's also customized to our particular preferences and needs.



If you are not OK with topics like this, why you don't create off-topic category 
where it should be fine to post topics what are not focused on D?


This forum is for D, and supporting off-topic forums is not part of our purpose.

I enjoy arguing about politics myself, but not here. I recommend using reddit 
for politics.


For here, I appreciate everyone maintaining professional demeanor and keeping 
things reasonably about D.


If you'd like to review our Code of Conduct:

https://www.youtube.com/watch?v=eQRuNwOMzW8=PLBFA47360BEAFBC75

Re: Precise GC state

[Ola Fosheim Grostad via Digitalmars-d]

On Monday, 27 November 2017 at 06:47:00 UTC, Dmitry Olshansky 
wrote:
Last time I check shared_ptr can be safely shared across 
threads, hence RC is takling synchronization and most likely 
atomics since locks won’t be any better.


The controlblock can, but it is crazy to use shared_ptr for 
anything more than high level ownership. It is a general solution 
with weak pointers and extra indirection, not a typical RC 
implementation for datastructures.



In C++ sync is manual, which is the only efficient way to do


??? shared_ptr is nowhere manual.


There is an upcoming atomic_shared_ptr, but it is not in the 
standard yet.


My post is about particular primitive in C++ std, what could be 
done instead or in addition to is not important.


Oh, but it is.

1. D currently does not provide what you says it does.

2. Sane C++ programmers rarely use shared_ptr for more than 
exchsnging ownership (suitable for sharing things like bitmap 
textures). There are plenty of other RC implementations for 
tracking memory. So you compare apples and oranges.

Re: Precise GC state

[Petar via Digitalmars-d]

On Monday, 27 November 2017 at 06:36:27 UTC, Ola Fosheim Grostad 
wrote:
On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky 
wrote:
likely via RAII. Not to mention cheap (thread-local) Ref 
Counting, C++ and many other language have to use atomics 
which makes RC costly.


No, you dont. Nobody in their right mind would do so in C++ as 
a general solution. Seems there is trend in doing D-advocacy 
based on the assumption that programmers using other languages 
are crazy these days.


In C++ sync is manual, which is the only efficient way to do 
it. Proving correctness for an efficient general solution is an 
unsolved theoretical problem. You can do it for high level 
mechanisms, but not low level atm.


Rust and Pony claims to have solutions, but they are not 
general. D most certainly does not have it and never will.


When threading is a libray type then you cannot achieve more in 
D than you can achieve in C++, i.e. Shared is not going to do 
more than a C++ library type with a separate static analysis 
tool.


What I think Dmitry meant is that shared_ptr uses atomic 
instructions for the reference counting (though you need to use 
atomic_shared_ptr, or atomic_* function if you want to modify the 
shared_ptr itself) and you can't opt out of that even if you're 
not sharing the shared_ptr with other threads. On the other hand 
in D, a properly designed SharedPtr(T) will use atomic 
instructions for reference counting, only if it's payload type T 
is has the 'shared' type qualifier. And if you have 
'shared(SharedPtr(T))', only then you'll have atomic instructions 
for the SharedPtr struct itself, but unlike shared_ptr, you 
won't have access to the non-thread safe methods.

Re: Precise GC state

[Dmitry Olshansky via Digitalmars-d]

On Monday, 27 November 2017 at 06:36:27 UTC, Ola Fosheim Grostad 
wrote:
On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky 
wrote:
likely via RAII. Not to mention cheap (thread-local) Ref 
Counting, C++ and many other language have to use atomics 
which makes RC costly.


No, you dont. Nobody in their right mind would do so in C++ as 
a general solution. Seems there is trend in doing D-advocacy 
based on the assumption that programmers using other languages 
are crazy these days.


Last time I check shared_ptr can be safely shared across threads, 
hence RC is takling synchronization and most likely atomics since 
locks won’t be any better.




In C++ sync is manual, which is the only efficient way to do


??? shared_ptr is nowhere manual.

Sorry but the rest of the of post is take a direction into the 
fog, that I don’t want to follow.


My post is about particular primitive in C++ std, what could be 
done instead or in addition to is not important.

Re: Thoughts about D

[Walter Bright via Digitalmars-d]

On 11/26/2017 9:11 PM, Neia Neutuladh wrote:
The culprit for the C# version's poor performance was System.String.Substring, 
which allocates a copy of its input data. So "Hello world".Substring(5) creates 
a new char* pointing at a new memory allocation containing "Hello\0". C++'s 
std::string does the same thing. So if I reimplemented subtex naively in C++, 
its performance would be closer to the C# version than to the D version.


I could probably get slightly better performance than the D version by writing a 
special `stringslice` struct. But that's a lot of work, and it's currently just 
barely fast enough that I realize that I've actually run the command instead of 
my shell inexplicably swallowing it.


0 terminated strings in C (and C++) have always been a severe performance issue 
for programs that deal a lot in strings, for these reasons:


1. To get a substring, a copy must be made, meaning also that storage allocated 
and managed for it.


2. To do most operations on it, you need to do a strlen() or equivalent.

You can always write your own string package to deal with, and I've written many 
:-( and they all failed for one reason or another, mostly because about 
everything in the C/C++ ecosystem is built around 0 terminated strings.

Re: Precise GC state

[Ola Fosheim Grostad via Digitalmars-d]

On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky 
wrote:
likely via RAII. Not to mention cheap (thread-local) Ref 
Counting, C++ and many other language have to use atomics which 
makes RC costly.


No, you dont. Nobody in their right mind would do so in C++ as a 
general solution. Seems there is trend in doing D-advocacy based 
on the assumption that programmers using other languages are 
crazy these days.


In C++ sync is manual, which is the only efficient way to do it. 
Proving correctness for an efficient general solution is an 
unsolved theoretical problem. You can do it for high level 
mechanisms, but not low level atm.


Rust and Pony claims to have solutions, but they are not general. 
D most certainly does not have it and never will.


When threading is a libray type then you cannot achieve more in D 
than you can achieve in C++, i.e. Shared is not going to do more 
than a C++ library type with a separate static analysis tool.

Re: Thoughts about D

[Dmitry Olshansky via Digitalmars-d]

On Monday, 27 November 2017 at 01:03:29 UTC, Adam Wilson wrote:

On 11/26/17 16:14, IM wrote:

Hi,
I'm a full-time C++ software engineer in Silicon Valley. I've 
been
learning D and using it in a couple of personal side projects 
for a few

months now.

[snip]


I could add more, but I'm tired of typing. I hope that one day 
I will
overcome my frustrations as well as D becomes a better 
language that

enables me to do what I want easily without standing in my way.


Well. D has it's own idioms and patterns. So we fully expect 
some of the idioms that are easy in C++ to be not easy in D, 
and indeed that's kind of the point. If you look at the those 
idioms that are hard in D, it's probably because said idiom 
allows you to do some fantastically unsafe (and insecure) thing 
in C++. Yes, I am sure that it gives some performance boost, 
but D is not trying to be the pinnacle of language performance.


It sure does. Otherwise there are plenty languages that are safe 
and somewhat fast.

C# or Java fit the bill nicely. Also Go.


D is trying to be a memory-safe language, quite intentionally


And thus @system is the default, right?
I think memory safety came as an afterthought.

at the expense of speed (see this DConf 2017 talk: 
https://www.youtube.com/watch?v=iDFhvCkCLb4=1=PL3jwVPmk_PRxo23yyoc0Ip_cP3-rCm7eB). Bounds checking by default, GC, etc. are all memory safety features that come explicitly at the cost of performance.


We are not trying to be C++


True, albeit doesn’t feel like that.


and we are not trying to replace C++


Patently false.

It sounds like C++ works better for you. We are OK with that. 
We always recommend using what works best for you. That is 
after all why WE are here. :)


That WE might have been just you :)
D certainly tries to replace C++ in a number of ways. It’s not a 
drop-in replacement and doesn’t cover all of C++ niche.

Re: Looking for a job in USA

[Satoshi via Digitalmars-d]

Thanks everyone for your advices and helping me with finding job 
in the US. I applied for about 300 jobs at companies like Apple, 
M$, Amazon, Google, etc. and got one offer in Canada, so it's 
half-win for me. :)


Thanks!

BTW: Walter, why you don't use IP Board instead of this, custom 
made forum? If you are not OK with topics like this, why you 
don't create off-topic category where it should be fine to post 
topics what are not focused on D?

Re: Thoughts about D

[Ola Fosheim Grostad via Digitalmars-d]

On Monday, 27 November 2017 at 05:11:06 UTC, Neia Neutuladh wrote:
You might say that I could use C++ style manual memory 
management and get even better performance. And you'd be wrong.


No... Not if you do it right, but it takes more planning. I.e. 
Design. Which is why scripting and high level languages dont use 
it.


std::string does the same thing. So if I reimplemented subtex 
naively in C++, its performance would be closer to the C# 
version than to the D version.


You meant stupidly, you would rather use std::string_view for 
string references in C++. std::string is a library convenience 
type that typically is only used for debugging and filenames. If 
you want performance then it really isnt possible to make do with 
a fixed library type for strings so in a realistic program people 
would write their own.


I could probably get slightly better performance than the D 
version by writing a special `stringslice` struct. But that's a 
lot of work,


No...

On the whole, it sounds like you don't like D because it's not 
C++. Which is fine, but D isn't going to become C++.


Sure. But maybe you shouldn't use a tiny 400k input when 
discussing performance. Try to think about how many instructions 
a CPU executes in 50ms...


If you dont know C++ then it makes no sense for you to compare 
performance to C++.

Re: Precise GC state

[Dmitry Olshansky via Digitalmars-d]

On Sunday, 26 November 2017 at 18:58:04 UTC, jmh530 wrote:
On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky 
wrote:


If all of the code is 100% @safe (not system and not trusted) 
you have a different language where write barriers would be 
cheaper to implement.


Sadly you can’t “skip” write barriers in your @system code 
because it may run as part of larger @safe. Which is where 
they are the most costly.


I was thinking you would use a generational or precise GC for 
@safe code and then fall back to the normal GC with 
@system/@trusted code.


Wishful thinking. Memory flows through a program and things 
allocated in @safe get passed to @system (including the last 
reference cases) and vise versa.


Also in D generational hypothesis may not bear as much value due 
to stack-allocation, libc heap allocations for temporaries likely 
via RAII. Not to mention cheap (thread-local) Ref Counting, C++ 
and many other language have to use atomics which makes RC costly.


Basically the GC heap is not all of the heap, so a young objects 
is even smaller part of that.


Lastly it is telling that new low-latency concurrent GCs do away 
without explicit generations.


I’m thinking a more efficient way to takle temporaries would be 
to add Regions to GC.
So the moment you enter a region all GC things are allocated in a 
special segment, once you leave it free the segment. The last 
trick is to tweak memory protection as guard pages over it. Boom! 
Now if somebody touches it - DanglingPointerException :)


Not a panacea but:
- libraries using too much of GC can be controlled (unless they 
build global state)

- manual memory management without memory corruption
- fast bump allocation, which is what all of sensible VM 
languages do


And no need to create entire separate heap with its own 
generational schema.


Not sure if that's possible or not, but in my head it would be 
a separate heap from the @safe code.


And then I do append in @system on array allocated in @safe. Boom!


Certainly would be added complexity.

Re: Thoughts about D

[Neia Neutuladh via Digitalmars-d]

On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:
- ‎It's quite clear that D was influenced a lot by Java at some 
point, which led to borrowing (copying?) a lot of Java features 
that may not appeal to everyone.


Have you observed a human to exist who has complained about a 
specific feature in D that is similar to a feature in Java? 
Relaying their complaints would be much more useful.


- ‎The amount of trickeries required to avoid the GC and do 
manual memory management are not pleasant and counter 
productive. I feel they defeat any productivity gains the 
language was supposed to offer.


Since so much of C++'s coding style revolves around memory 
management, the idea that you might be able to avoid manual 
memory management and still not see a giant reduction in 
performance is transformative. It means writing code in an 
entirely different style. And because Java is the point of 
comparison for using a garbage collector, it's easy to think that 
a GC is impossibly inefficient. But that's because Java abuses 
its GC so heavily (and because Java came out in an era when 
having 64MB of RAM on a home computer was pretty swish).


Let's compare with how D uses the GC. Here's an example of code 
that I wrote in the most obvious way possible that is more 
efficient than the equivalent in C++, specifically because of the 
garbage collector:


https://github.com/dhasenan/subtex

The only nods to performance in that are when I have various 
Appenders reserve some space in advance.


On my 410KB reference document, this completes in 50ms. (That's 
90ms faster than a Java "hello world" program.) I ported it to C# 
for comparison, and it took over one second. I ran a GC profiler 
and discovered that it allocated 4GB in string data.


The D version, by contrast, allocates a total of 12MB, runs three 
GC collections, and has a total pause time under 1ms. (If I add a 
call to `GC.collect()` just before the application exits, the 
total pause time exceeds 1ms but is still below 2ms.)


You might say that I could use C++ style manual memory management 
and get even better performance. And you'd be wrong.


The culprit for the C# version's poor performance was 
System.String.Substring, which allocates a copy of its input 
data. So "Hello world".Substring(5) creates a new char* pointing 
at a new memory allocation containing "Hello\0". C++'s 
std::string does the same thing. So if I reimplemented subtex 
naively in C++, its performance would be closer to the C# version 
than to the D version.


I could probably get slightly better performance than the D 
version by writing a special `stringslice` struct. But that's a 
lot of work, and it's currently just barely fast enough that I 
realize that I've actually run the command instead of my shell 
inexplicably swallowing it.



On the whole, it sounds like you don't like D because it's not 
C++. Which is fine, but D isn't going to become C++.

Re: Thoughts about D

[codephantom via Digitalmars-d]

On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:
- D is unnecessarily a huge language. I remember in DConf 2014, 
Scott Meyers gave a talk about the last thing D needs, which is 
a guy like him writing a lot of books covering the many 
subtleties of the language. However, it seems that the D 
community went ahead and created exactly this language!


btw. I found this interesting article from Rob Pike (golang).

https://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-more.html

He discusses the reasons why C++ developers are *not* flocking to 
Go...which interestingly, is the very opposite with regards to D 
(well 'flocking' might be a slight over exaggeration ;-)


Neither (Go's) 'unnecessarily small philosophy', or (C++'s) 
'unnecessarily huge philosophy' are good design philosophies. Go 
programmers will eventually look for 'more', and C++ programmers 
will continue to look for 'less'.


"When all the forces acting upon an object balance each other, 
the object will be at equilibrium."

Re: Thoughts about D

[Jon Degenhardt via Digitalmars-d]

On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:
I'm a full-time C++ software engineer in Silicon Valley. I've 
been learning D and using it in a couple of personal side 
projects for a few months now.


First of all, I must start by saying that I like D, and wish to 
use it everyday. I'm even considering to donate to the D 
foundation. However, some of D features and design decisions 
frustrates me a lot, and sometimes urges me to look for an 
alternative. I'm here not to criticize, but to channel my 
frustrations to whom it may concern. I want D to become better 
and more widely used. I'm sure many others might share with me 
some of the following points:


Forum discussions are valuable venue. Since you are in Silicon 
Valley, you might also consider attending one of the Silicon 
Valley D meetups (https://www.meetup.com/D-Lang-Silicon-Valley). 
It's hard to beat face-to-face conversations with other 
developers to get a variety of perspectives. The ultimate would 
be DConf, if you can manage to attend.

Re: Thoughts about D

[Walter Bright via Digitalmars-d]

On 11/26/2017 4:14 PM, IM wrote:
I'm a full-time C++ software engineer in Silicon Valley. I've been learning D 
and using it in a couple of personal side projects for a few months now.


Great! Glad you're enjoying it and took the time to post your thoughts.


- D is unnecessarily a huge language. I remember in DConf 2014, Scott Meyers 
gave a talk about the last thing D needs, which is a guy like him writing a lot 
of books covering the many subtleties of the language. However, it seems that 
the D community went ahead and created exactly this language!


You'll find the same language in 2014 as today, it hasn't changed much. All 
languages (except C) in common use accrete features.


D does have some baggage that has been removed, like `typedef`, but on the whole 
whenever we try to remove something, someone always has built their store around it.


The good news, however, is just use the subset of D that works for you.


- ‎D is very verbose. It requires a lot of typing. Look at how long 'immutable' 
is. Very often that I find myself tagging my methods with something like 'final 
override nothrow @safe @nogc ...' etc.


The idea is if you just want to write code, you can eschew using them (except 
'override'), and just write code. They're all used for optimization or to 
provide enforceable self-documentation. Other languages would require those to 
be documented in the comments, which is not enforceable and even more wordy :-)


'override' is as opposed to 'virtual' which C++ requires and D doesn't.


- ‎It's quite clear that D was influenced a lot by Java at some point, which led 
to borrowing (copying?) a lot of Java features that may not appeal to everyone.


That's true. Java looked like it was going to take over the world when D was 
young. These days I'd get rid of inner classes in favor of lambdas if I could, 
but you can just ignore inner classes.



- ‎The amount of trickeries required to avoid the GC and do manual memory 
management are not pleasant and counter productive. I feel they defeat any 
productivity gains the language was supposed to offer.


That's true. But it's hard to beat GC for just writing code and getting it to 
run safely and without pointer bugs.



- ‎The thread local storage, shared, and __gshared business is annoying and 
doesn't seem to be well documented, even though it is unnatural to think about 
(at least coming from other languages).


The idea with TLS is to deal with endemic threading bugs other languages have. 
The default in C/C++ is for globals to be shared, which is completely 
impractical to examine a large code base for. __gshared is meant to stand out 
and be greppable, making code much more auditable.



- ‎D claims to be a language for productivity, but it slows down anyone thinking 
about efficiency, performance, and careful design decisions. (choosing structs 
vs classes, structs don't support hierarchy, use alias this, structs don't allow 
default constructors {inconsistent - very annoying}, avoiding the GC, look up 
that type to see if it's a struct or a class to decide how you may use it ... 
etc. etc.).


D structs are value types, and classes are reference types. Everything flows 
from that. C++ structs and classes are the same thing, and can be used as both 
reference and value types at the same time, whether that works or not. I rarely 
find C++ classes with documentation saying if they are intended as a reference 
or value type, and the documentation won't prevent one from misusing it.


I'm not the only one to suggest that making the value/ref design decision is a 
pretty crucial one to make before designing the code. :-)



I could add more, but I'm tired of typing. I hope that one day I will overcome 
my frustrations as well as D becomes a better language that enables me to do 
what I want easily without standing in my way.


Many people have difficulty with D when coming from, say, C++, because it does 
require a different way of thinking about code. This passes once one gains 
experience and comfort with D. After all, my early Fortran code looked just like 
BASIC, my C code looked like Fortran, my C++ code looked like "C with a few 
classes", and my D code looked a bit too much like C++ :-)


I have recently finished converting the Digital Mars C++ compiler front end from 
"C with classes" to D. Even though it is a rote line-by-line translation, it 
simply looks better in D (much less of a snarl). Over time, as I refactor bits 
of it, it'll steadily look better. I find it significantly easier to write good 
looking code in D, and it is less verbose than C++.


For some trivial examples,

C++: unsigned long long
D: ulong

C++: template struct S { ... };
D: struct S(T) { ... }

C++: for (int i = 0; i < 10; ++i)
D: foreach (i; 0..10)

C++: decltype
D: auto

Re: Thoughts about D

[rikki cattermole via Digitalmars-d]

On 27/11/2017 12:14 AM, IM wrote:

snip

- ‎D is very verbose. It requires a lot of typing. Look at how long 
'immutable' is. Very often that I find myself tagging my methods with 
something like 'final override nothrow @safe @nogc ...' etc.


There be solutions here!

struct Foo {
final nothrow @safe @nogc {
void a() {}
void b() {}
}
}

Re: Is variable void?

[codephantom via Digitalmars-d-learn]

On Saturday, 25 November 2017 at 15:34:21 UTC, John Chapman wrote:
Is there any way of determining whether a variable has been 
initialized or not? For example, if something is declared like 
this:


  int x = void;

can I check if it's void before I use it, say, in a function 
it's been passed to?


// --

module test;

import std.stdio;
import std.typecons; // see: 
https://dlang.org/phobos/std_typecons.html#Nullable


void main()
{
Nullable!int x;  // requires: import std.typecons
assert(x.isNull);
writeln("x is ", x);

x = 1;
assert(!x.isNull);
writeln("x is ", x);

x.nullify(); // Forces x back to a null state.
assert(x.isNull);
writeln("x is ", x);

}
// --

Re: Precise GC state

[jmh530 via Digitalmars-d]

On Sunday, 26 November 2017 at 19:11:08 UTC, Jonathan M Davis 
wrote:


It wouldn't work. @safe code and @system code call each other 
all the time (using @trusted where necessary), and they freely 
exchange stuff that was allocated on the GC heap. [snip]


I see. Fair enough.

Re: Thoughts about D

[Michael V. Franklin via Digitalmars-d]

On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:

- D is unnecessarily a huge language. I remember in DConf 2014, 
Scott Meyers gave a talk about the last thing D needs, which is 
a guy like him writing a lot of books covering the many 
subtleties of the language. However, it seems that the D 
community went ahead and created exactly this language!


IMO, I don't think it's too bad.  I'd rather have those features, 
than not have them.  One of the best features of D is it's 
modeling power.  Due to the rich feature set of D, you can model 
your code exactly how you think about it; you don't have to 
change the way you think about a problem to accommodate the 
limitations of your programming language.


Furthermore, compared to C++, the end results is MUCH better.  
I've written a small memory-mapped IO library in both C++ and D.  
It heavily leverages templates and compile-time features of both 
languages.  The C++ version turned into a monstrosity that even 
I, the author, couldn't understand.  The D version was quite 
beautiful and elegant, much less verbose, and even had a few 
features I couldn't figure out how to do in C++.


- ‎D is very verbose. It requires a lot of typing. Look at how 
long 'immutable' is. Very often that I find myself tagging my 
methods with something like 'final override nothrow @safe @nogc 
...' etc.


I agree, but I don't think it's as bad as C++ (see my comment 
above).  But, unfortunately, D has chosen the wrong defaults, IMO:


(1) We should be opting out of @safe, not opting into it
(2) D should be final-by-default (See 
https://wiki.dlang.org/Language_design_discussions#final-by-default for how that got shot down)
(3) Perhaps D should be nothrow by default, but I'm not sure 
exactly how that would work
(4) As a systems programming language first and an applications 
programming language second, I argue that the GC should be 
something we opt into, not opt out of.  With `scope` and DIP 1000 
features, we may eventually get there.
(5) I think variables should be `immutable` by default like they 
are in Rust, but others disagree.


You get the idea.  I think part of this is due to historical 
accidents.  D is, unfortunately, carrying a lot of technical debt.


- ‎It's quite clear that D was influenced a lot by Java at some 
point, which led to borrowing (copying?) a lot of Java features 
that may not appeal to everyone.


Many seem to think of D as a better C++, but like you, I see more 
of an influence from Java too.  I like the convenience of *some* 
of those Java-like features.  So, I consider the influence of 
Java somewhat of a strength in D.


- ‎The amount of trickeries required to avoid the GC and do 
manual memory management are not pleasant and counter 
productive. I feel they defeat any productivity gains the 
language was supposed to offer.


I agree.  See the documentation for `scope` and DIP1000.  I think 
the situation may get better if we can continue momentum on those 
features.


https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md

There's also been some recent work this month on RAII with 
-betterC which may be of interest to you. But I still see 
-betterC as a copout, avoiding the difficult work of decoupling 
the compiler from the runtime.


- ‎The thread local storage, shared, and __gshared business is 
annoying and doesn't seem to be well documented, even though it 
is unnatural to think about (at least coming from other 
languages).


I think the thread local storage is a great feature of D.  It's 
one of the defaults that D actually got right.  I don't care for 
the double-underscore convention of __gshared that seems to be 
borrowed from C, but we're lucky to have it.  It comes in handy 
sometimes.


It's hard to know what difficulty users encounter when reading 
the documentation.  If you think it can be improved, please 
submit a pull request to https://github.com/dlang/dlang.org


- ‎D claims to be a language for productivity, but it slows 
down anyone thinking about efficiency, performance, and careful 
design decisions. (choosing structs vs classes, structs don't 
support hierarchy, use alias this, structs don't allow default 
constructors {inconsistent - very annoying}, avoiding the GC, 
look up that type to see if it's a struct or a class to decide 
how you may use it ... etc. etc.).


I run into those design dilemmas any time I start learning a new 
programming language, even with highly productive languages like 
C#.  It takes time for me to work through a few ideas and finally 
arrive at the right idioms that work.  But once they get worked 
out, it's cooking with gas.


I could add more, but I'm tired of typing. I hope that one day 
I will overcome my frustrations as well as D becomes a better 
language that enables me to do what I want easily without 
standing in my way.


Thanks for sharing your thoughts.  It's always interesting to 
hear what people think.


Mike

Re: Thoughts about D

[Guillaume Piolat via Digitalmars-d]

On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:

Hi,
I'm a full-time C++ software engineer in Silicon Valley. I've 
been learning D and using it in a couple of personal side 
projects for a few months now.


First of all, I must start by saying that I like D, and wish to 
use it everyday. I'm even considering to donate to the D 
foundation. However, some of D features and design decisions 
frustrates me a lot, and sometimes urges me to look for an 
alternative. I'm here not to criticize, but to channel my 
frustrations to whom it may concern. I want D to become better 
and more widely used. I'm sure many others might share with me 
some of the following points:
- D is unnecessarily a huge language. I remember in DConf 2014, 
Scott Meyers gave a talk about the last thing D needs, which is 
a guy like him writing a lot of books covering the many 
subtleties of the language. However, it seems that the D 
community went ahead and created exactly this language!
- ‎D is very verbose. It requires a lot of typing. Look at how 
long 'immutable' is. Very often that I find myself tagging my 
methods with something like 'final override nothrow @safe @nogc 
...' etc.
- ‎It's quite clear that D was influenced a lot by Java at some 
point, which led to borrowing (copying?) a lot of Java features 
that may not appeal to everyone.
- ‎The amount of trickeries required to avoid the GC and do 
manual memory management are not pleasant and counter 
productive. I feel they defeat any productivity gains the 
language was supposed to offer.
- ‎The thread local storage, shared, and __gshared business is 
annoying and doesn't seem to be well documented, even though it 
is unnatural to think about (at least coming from other 
languages).
- ‎D claims to be a language for productivity, but it slows 
down anyone thinking about efficiency, performance, and careful 
design decisions. (choosing structs vs classes, structs don't 
support hierarchy, use alias this, structs don't allow default 
constructors {inconsistent - very annoying}, avoiding the GC, 
look up that type to see if it's a struct or a class to decide 
how you may use it ... etc. etc.).


I could add more, but I'm tired of typing. I hope that one day 
I will overcome my frustrations as well as D becomes a better 
language that enables me to do what I want easily without 
standing in my way.


Hi and welcome here,

I've been using D for 10 years (fulltime since 3), and my 
frustrations almost mirrors yours. Probably the C++background?


I don't think D complexity negates productivity in the long run, 
but you get to avoid a lot of the language in daily operations. 
For me: pure, shared, synchronized and TLS-by-default are _not_ 
pulling their weight (off the top of my head).


Being a language "that can do what C++ can do" comes with large 
requirements both in capabilities and standard library. A 
language also seems more complex when we are more interested in 
it and eager to learn details (C++ may teach you to give up early 
on that point).


If you think about it, D has only l-values and r-values which is 
much simpler than where we were before. Actually I think a "Scott 
Meyers of D" would have difficulty coming up with four books of 
guidelines.


The good news is that you _can_ learn D in excrutiating detail, 
it's not something out of reach during a lifespan. The bad news 
is that the language accumulated complexity at one point and it 
can only be a long neural process (though initial familiarity 
helps a lot). I don't think anyone would have described D1 as 
verbose!



(Now defending no-default-constructor-for-structs: it's because 
S.init is supposed to be a valid struct - which implies your 
destructors should be reentrant. Buy the book for 50+ other tips)

Re: Thoughts about D

[codephantom via Digitalmars-d]

On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:
- D is unnecessarily a huge language. I remember in DConf 2014, 
Scott Meyers gave a talk about the last thing D needs, which is 
a guy like him writing a lot of books covering the many 
subtleties of the language. However, it seems that the D 
community went ahead and created exactly this language!


I hear this argument a lot, about this language or that.

It has become an argument void of any real value, in my view.

The reason is, programming needs have changed a lot, the problems 
being solved have changed alot, there is a great diversity in how 
people think about solving those problems, and a greater need to 
solve problems that are not solvable with current langauges.


So languages necessarily evolve according to the pressures put 
upon them by the environment in which they exist.


As for using features from other languages, this is a normal 
process of evolution -  convergent evolution. A language that is 
getting smaller, is NOT a language that is evolving (such a 
language is useful in a particular domain only).


The question is really not how 'huge' a language should or should 
not be. The question is how we can grasp that hugeness. The 
universe is huge, and extremely complex. But it can be understood 
(to an extent) according to some pretty basic principles. The 
human brain is equally 'huge' and 'complex'...but we are slowly 
coming to grips with (some of) it's basic princplez (deliberate 
spelling mistake for my friends ;-).


- ‎D is very verbose. It requires a lot of typing. Look at how 
long 'immutable' is. Very often that I find myself tagging my 
methods with something like 'final override nothrow @safe @nogc 
...' etc.


Sorry..what. You program in C++ and you're saying D is very 
verbose ;-)


I do think though, that function headers are becoming far too 
long  but this maybe something that one just has to accept, 
if one wants to have those choices.


i.e. You can only really make them shorter, by not allowing the 
programmer to have those choices. And if D is about anything, 
it's about programmer choices.


- ‎D claims to be a language for productivity, but it slows 
down anyone thinking about efficiency, performance, and careful 
design decisions. (choosing structs vs classes, structs don't 
support hierarchy, use alias this, structs don't allow default 
constructors {inconsistent - very annoying}, avoiding the GC, 
look up that type to see if it's a struct or a class to decide 
how you may use it ... etc. etc.).




Some very smart people who design programming languages think ALL 
inheritance should be completely banned. I'd be very happy if 
that were the case. Personally, I find it very easy to be 
productive in D, without classes. It's annoying language/library 
bugs that slow down my productivity.


But think of D as a work in progress...like galaxies crashing 
into each other.. it doesn't happen very often..so enjoy it while 
you can.

Re: Thoughts about D

[Adam Wilson via Digitalmars-d]

On 11/26/17 16:14, IM wrote:

Hi,
I'm a full-time C++ software engineer in Silicon Valley. I've been
learning D and using it in a couple of personal side projects for a few
months now.

First of all, I must start by saying that I like D, and wish to use it
everyday. I'm even considering to donate to the D foundation. However,
some of D features and design decisions frustrates me a lot, and
sometimes urges me to look for an alternative. I'm here not to
criticize, but to channel my frustrations to whom it may concern. I want
D to become better and more widely used. I'm sure many others might
share with me some of the following points:
- D is unnecessarily a huge language. I remember in DConf 2014, Scott
Meyers gave a talk about the last thing D needs, which is a guy like him
writing a lot of books covering the many subtleties of the language.
However, it seems that the D community went ahead and created exactly
this language!
- ‎D is very verbose. It requires a lot of typing. Look at how long
'immutable' is. Very often that I find myself tagging my methods with
something like 'final override nothrow @safe @nogc ...' etc.
- ‎It's quite clear that D was influenced a lot by Java at some point,
which led to borrowing (copying?) a lot of Java features that may not
appeal to everyone.
- ‎The amount of trickeries required to avoid the GC and do manual
memory management are not pleasant and counter productive. I feel they
defeat any productivity gains the language was supposed to offer.
- ‎The thread local storage, shared, and __gshared business is annoying
and doesn't seem to be well documented, even though it is unnatural to
think about (at least coming from other languages).
- ‎D claims to be a language for productivity, but it slows down anyone
thinking about efficiency, performance, and careful design decisions.
(choosing structs vs classes, structs don't support hierarchy, use alias
this, structs don't allow default constructors {inconsistent - very
annoying}, avoiding the GC, look up that type to see if it's a struct or
a class to decide how you may use it ... etc. etc.).

I could add more, but I'm tired of typing. I hope that one day I will
overcome my frustrations as well as D becomes a better language that
enables me to do what I want easily without standing in my way.


Well. D has it's own idioms and patterns. So we fully expect some of the 
idioms that are easy in C++ to be not easy in D, and indeed that's kind 
of the point. If you look at the those idioms that are hard in D, it's 
probably because said idiom allows you to do some fantastically unsafe 
(and insecure) thing in C++. Yes, I am sure that it gives some 
performance boost, but D is not trying to be the pinnacle of language 
performance. D is trying to be a memory-safe language, quite 
intentionally at the expense of speed (see this DConf 2017 talk: 
https://www.youtube.com/watch?v=iDFhvCkCLb4=1=PL3jwVPmk_PRxo23yyoc0Ip_cP3-rCm7eB). 
Bounds checking by default, GC, etc. are all memory safety features that 
come explicitly at the cost of performance.


We are not trying to be C++ and we are not trying to replace C++. It 
sounds like C++ works better for you. We are OK with that. We always 
recommend using what works best for you. That is after all why WE are 
here. :)


--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Thoughts about D

[IM via Digitalmars-d]

Hi,
I'm a full-time C++ software engineer in Silicon Valley. I've 
been learning D and using it in a couple of personal side 
projects for a few months now.


First of all, I must start by saying that I like D, and wish to 
use it everyday. I'm even considering to donate to the D 
foundation. However, some of D features and design decisions 
frustrates me a lot, and sometimes urges me to look for an 
alternative. I'm here not to criticize, but to channel my 
frustrations to whom it may concern. I want D to become better 
and more widely used. I'm sure many others might share with me 
some of the following points:
- D is unnecessarily a huge language. I remember in DConf 2014, 
Scott Meyers gave a talk about the last thing D needs, which is a 
guy like him writing a lot of books covering the many subtleties 
of the language. However, it seems that the D community went 
ahead and created exactly this language!
- ‎D is very verbose. It requires a lot of typing. Look at how 
long 'immutable' is. Very often that I find myself tagging my 
methods with something like 'final override nothrow @safe @nogc 
...' etc.
- ‎It's quite clear that D was influenced a lot by Java at some 
point, which led to borrowing (copying?) a lot of Java features 
that may not appeal to everyone.
- ‎The amount of trickeries required to avoid the GC and do 
manual memory management are not pleasant and counter productive. 
I feel they defeat any productivity gains the language was 
supposed to offer.
- ‎The thread local storage, shared, and __gshared business is 
annoying and doesn't seem to be well documented, even though it 
is unnatural to think about (at least coming from other 
languages).
- ‎D claims to be a language for productivity, but it slows down 
anyone thinking about efficiency, performance, and careful design 
decisions. (choosing structs vs classes, structs don't support 
hierarchy, use alias this, structs don't allow default 
constructors {inconsistent - very annoying}, avoiding the GC, 
look up that type to see if it's a struct or a class to decide 
how you may use it ... etc. etc.).


I could add more, but I'm tired of typing. I hope that one day I 
will overcome my frustrations as well as D becomes a better 
language that enables me to do what I want easily without 
standing in my way.

[Issue 18015] [Reg 2.075] link failure unknown [0] section `' in group [.group]

[d-bugmail--- via Digitalmars-d-bugs]

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

Mike  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com

--- Comment #1 from Mike  ---
> Will this error message be enough or do I need to provide more information on 
> the issue?

A reduced test case would be most helpful.

--

[Issue 18015] New: [Reg 2.075] link failure unknown [0] section `' in group [.group]

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18015
   Summary: [Reg 2.075] link failure unknown [0] section `' in
group [.group]
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: lluce...@gmail.com

Pull request #6564 (indicated by digger) definitively causes a regression
besides the one solved in issue 17338. This regression is valid for DMD
releases since 2.075.0 thru 2.077.0 (at the time of this writing).

I have a project split in dub configuration into three subpackages. When I try
to build it monolithic (all source files at once) the build succeeds.
But when I let the subpackages be built as libraries and linked into the final
binary I get linker errors:

---
Linking...
/usr/bin/ld:
.dub/build/library-debug-linux.posix-x86_64-dmd_2075-6DE222CFD88EDD0D48F9BB14A21E15BC/libars-engine.a(log_840_28d9.o):
unknown [0] section `' in group [.group]
/usr/bin/ld:
.dub/build/library-debug-linux.posix-x86_64-dmd_2075-6DE222CFD88EDD0D48F9BB14A21E15BC/libars-engine.a(log_840_28d9.o):
unknown [0] section `' in group [.group]
.dub/build/library-debug-linux.posix-x86_64-dmd_2075-6DE222CFD88EDD0D48F9BB14A21E15BC/libars-engine.a:
error adding symbols: File format not recognized
collect2: error: ld returned 1 exit status
Error: linker exited with status 1
dmd failed with exit code 1.
---

Content of the library that is built from one of the subpackages (ars-engine)
is corrupt. Utility 'nm' reports for some object files within the library the
same error (see the issue title) as the linker in the later phase when building
the application.


The project is built on top of vibe.d, what may be somehow connected with
https://ci.dlang.io/blue/organizations/jenkins/dlang-org%2Fdmd/detail/PR-6564/17/pipeline/

Will this error message be enough or do I need to provide more information on
the issue?

--

[Issue 12496] __traits(parent, x) returns incorrect type

[d-bugmail--- via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 12496] __traits(parent, x) returns incorrect type

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/b74bb167d2bd49d47d01f0f19277b5441ade3afc
Fix Issue 12496: __traits(parent, x) returns incorrect symbol

https://github.com/dlang/dmd/commit/d94a080030193fb0514bc512265e18dfe4d973f0
Merge pull request #7097 from JinShil/fix_12496

Fix Issue 12496: __traits(parent, x) returns incorrect symbol
merged-on-behalf-of: Mike 

--

Re: Is variable void?

[crimaniak via Digitalmars-d-learn]

On Saturday, 25 November 2017 at 15:34:21 UTC, John Chapman wrote:
Is there any way of determining whether a variable has been 
initialized or not? For example, if something is declared like 
this:


  int x = void;

can I check if it's void before I use it, say, in a function 
it's been passed to?


 You can use Nullable!int

[Issue 18014] DMD test suite fails to build/run on Ubuntu 17.04 because -fPIC is not properly set

[d-bugmail--- via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

Summary|DMD test suite fails to |DMD test suite fails to
   |build/run on Ubuntu 17.04   |build/run on Ubuntu 17.04
   |due to PIC  |because -fPIC is not
   ||properly set

--

[Issue 18014] DMD test suite fails to build/run on Ubuntu 17.04 due to PIC

[d-bugmail--- via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|petar.p.ki...@gmail.com

--

[Issue 18014] New: DMD test suite fails to build/run on Ubuntu 17.04 due to PIC

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18014
   Summary: DMD test suite fails to build/run on Ubuntu 17.04 due
to PIC
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: petar.p.ki...@gmail.com

Steps to reproduce:
1) docker pull zombinedev/dmd-test-suite-docker

(Or alternatively,  'git clone
https://github.com/ZombineDev/dmd-test-suite-docker' followed by 'docker built
-t zombinedev/dmd-test-suite-docker .')

2) docker run zombinedev/dmd-test-suite-docker

I'm working on a pull-request.

--

Re: inout after function

[Guillaume Piolat via Digitalmars-d-learn]

On Saturday, 25 November 2017 at 21:51:41 UTC, Dave Jones wrote:

What does the "inout" after front() do here...


@property ref inout(T) front() inout
{
assert(_data.refCountedStore.isInitialized);
return _data._payload[0];
}

Cant seem to find an explanation in the docs or forums :(


https://p0nce.github.io/d-idioms/#Knowing-inout-inside-out

Re: Precise GC state

[Ola Fosheim Grostad via Digitalmars-d]

On Sunday, 26 November 2017 at 19:11:08 UTC, Jonathan M Davis 
wrote:
We can't even have different heaps for immutable and mutable 
stuff, because it's very common to construct something as 
mutable and then cast it to immutable (either explicitly or


This is easy to fix, introduce a uniquely owned type (isolated) 
that only can transition to immutable.


So it is more about being willing to tighten up the semantics. 
Same thing with GC, but everything has a cost.


That said Adam has a point with getting more users, it isnt 
obvious that the costs wouldnt be offset by increased interest. 
Anyway, it seems like C# and Swift are pursuing the domain D is 
in by gradually expanding into more performance oriented 
programming mechanisms... We'll see.

Re: Beta 2.077.1

[Jonathan M Davis via Digitalmars-d-announce]

On Sunday, November 26, 2017 03:30:27 Walter Bright via Digitalmars-d-
announce wrote:
> Too late for RAII for betterC? :-(

This is a point release, and adding RAII to betterC is a new feature.
Normally, only bug fixes are supposed to go in point releases.

- Jonathan M Davis

Re: Precise GC state

[Jonathan M Davis via Digitalmars-d]

On Sunday, November 26, 2017 18:58:04 jmh530 via Digitalmars-d wrote:
> On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky
>
> wrote:
> > If all of the code is 100% @safe (not system and not trusted)
> > you have a different language where write barriers would be
> > cheaper to implement.
> >
> > Sadly you can’t “skip” write barriers in your @system code
> > because it may run as part of larger @safe. Which is where they
> > are the most costly.
>
> I was thinking you would use a generational or precise GC for
> @safe code and then fall back to the normal GC with
> @system/@trusted code. Not sure if that's possible or not, but in
> my head it would be a separate heap from the @safe code.
> Certainly would be added complexity.

It wouldn't work. @safe code and @system code call each other all the time
(using @trusted where necessary), and they freely exchange stuff that was
allocated on the GC heap. Heck, it's not even possible to have per-thread
heaps (much as that would be desirable), because stuff can be passed between
threads, and you can freely cast between shared and non-shared. You do have
to be careful about it if you don't want to have problems, but just like
@safe code can call @trusted code such that it's possible for @safe code be
calling code that was vetted for memory safety by a programmer rather than
the compiler, you can have code that casts to and from shared and works
perfectly well so long as the programmer vets it properly.

We can't even have different heaps for immutable and mutable stuff, because
it's very common to construct something as mutable and then cast it to
immutable (either explicitly or because it's returned from a pure function
which is able to do the cast implicitly, because it knows that the return
value couldn't possibly have been passed into the function and thus had to
have been allocated inside it).

D's type system protects you from all kinds of dumb mistakes, but it has way
too many backdoors for the kind of stuff that requires that things be locked
down like they would be inside a VM like Java has. Ultimately, if you're
talking about a GC and what it can and can't do, I expect that there's very
little difference between C and D in terms of what you types of GC you can
get away with. D does protect the programmer, but ultimately, it lets you do
just about anything that C lets you do if you really want to, and any GC
that we use has to work with that.

- Jonathan M Davis

Re: Precise GC state

[jmh530 via Digitalmars-d]

On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky 
wrote:


If all of the code is 100% @safe (not system and not trusted) 
you have a different language where write barriers would be 
cheaper to implement.


Sadly you can’t “skip” write barriers in your @system code 
because it may run as part of larger @safe. Which is where they 
are the most costly.


I was thinking you would use a generational or precise GC for 
@safe code and then fall back to the normal GC with 
@system/@trusted code. Not sure if that's possible or not, but in 
my head it would be a separate heap from the @safe code. 
Certainly would be added complexity.

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #8 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/89c900316c02d7e845b151e02a460d89631a9d07
Fix Issue 15094 - __traits(getMember) fails when the source is a struct/class
field

https://github.com/dlang/dmd/commit/c9d988ebc0eca6137551eaacb961400acb2e7752
Merge pull request #7341 from JinShil/fix_15094

Fix Issue 15094 - __traits(getMember) fails when the source is a struct/class
field

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

[d-bugmail--- via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: Beta 2.077.1

[Paolo Invernizzi via Digitalmars-d-announce]

On Thursday, 23 November 2017 at 11:43:08 UTC, Martin Nowak wrote:

First beta for the 2.077.1 point release.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.077.1.html


Please report any bugs at https://issues.dlang.org

- -Martin


18012 is an ice regression towards 2.076.1 ...

/P

Re: DIP 1006 - Preliminary Review Round 1

[rikki cattermole via Digitalmars-d]

On 26/11/2017 11:59 AM, Joseph Rushton Wakeling wrote:

On Tuesday, 21 November 2017 at 14:15:30 UTC, Martin Nowak wrote:

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md


Has come up a couple of times and it's a good idea to allow more 
control over which checks are enabled.
I find the suggested switch levels a bit counter-intuitive and would 
suggest


  -release=assert,in,out,invariant

to be the equivalent of the current

  -release

while allowing to enable any subset


I like the idea of specializing the meaning of the -release flag via 
optional arguments.


One suggestion: replace -release=assert with -release=body, so in the 
above, you would have:


     -release=body,in,out,invariant

... which has the nice intuitive property of specifying _which bits of 
code_ release criteria will be applied to.


In other words, -release=body would result in asserts being removed from 
function bodies _and only there_.  That would make clearer that we're 
not removing asserts from e.g. unittests (or indeed contracts or 
invariants).


Agreed that looks good +1

Re: DIP 1006 - Preliminary Review Round 1

[Joseph Rushton Wakeling via Digitalmars-d]

On Tuesday, 21 November 2017 at 14:15:30 UTC, Martin Nowak wrote:

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md


Has come up a couple of times and it's a good idea to allow 
more control over which checks are enabled.
I find the suggested switch levels a bit counter-intuitive and 
would suggest


  -release=assert,in,out,invariant

to be the equivalent of the current

  -release

while allowing to enable any subset


I like the idea of specializing the meaning of the -release flag 
via optional arguments.


One suggestion: replace -release=assert with -release=body, so in 
the above, you would have:


-release=body,in,out,invariant

... which has the nice intuitive property of specifying _which 
bits of code_ release criteria will be applied to.


In other words, -release=body would result in asserts being 
removed from function bodies _and only there_.  That would make 
clearer that we're not removing asserts from e.g. unittests (or 
indeed contracts or invariants).

[Issue 17994] [Reg 2.077] Token.isKeyword() segfaults

[d-bugmail--- via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

Re: Beta 2.077.1

[Walter Bright via Digitalmars-d-announce]

Too late for RAII for betterC? :-(

Re: inout after function

[Dave Jones via Digitalmars-d-learn]

On Sunday, 26 November 2017 at 04:51:08 UTC, Adam D. Ruppe wrote:

On Sunday, 26 November 2017 at 01:35:01 UTC, Dave Jones wrote:
So it makes it a const/immutable/mutable method depending on 
whether the instance it is called on is 
const/immutable/mutable?


On the outside, yes.


So


@property ref inout(int) front() inout {
return i++;
}


Would fail if you called it on an immutable instance of S.


That wouldn't compile in any case: on the inside of the 
function, inout == const (this is the only way the one function 
can be used for all three). The inout propagation is just seen 
at the call site.


Ahh ok, makes sense now.

Re: Linking multiple libraries

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-11-25 23:31, Mike Parker wrote:

You don't link static libraries with each other. They're just 
collections of object files intended to be linked with an executable or 
a DLL. Order doesn't matter for optlink or the MS linker, but other 
linkers, such as ld (which is commonly used with GCC) require the 
libraries be passed in according to dependencies, e.g. dependent 
libraries come before their dependencies. Not sure if the LLVM linker 
retains that behavior.


For completeness:

For "ld" on macOS the order does not matter. For "ld" on Linux the order 
does matter, but, if necessary, the following flags can be used to link 
libraries in any order: "--start-group" and "--end-group". Those flag 
will cause the linker to search the libraries repeatedly to resolve 
undefined symbols.


--
/Jacob Carlborg

Re: SublimeLinter-contrib-dmd: dmd feedback as you type

[Manuel Maier via Digitalmars-d-announce]

On Monday, 30 October 2017 at 22:22:42 UTC, Bastiaan Veelo wrote:
[...] Unlike linters that are based on DScanner, it actually 
invokes dmd on the file that is being edited, as you edit. [...]


I just tried the plugin and it seems to work very well! Thanks 
for the good work.


Have you considered invoking dub instead of dmd if there's a 
dub.json/.sdl file? I imagine when people use "preBuildCommands" 
to generate code, for example, the linter might report false 
positives. Same goes for custom D versions (e.g. 
`version(Have_foo) { ... }`).


There's also the --single feature of dub: 
https://code.dlang.org/advanced_usage Such files may not work 
correctly with this linter at this time I presume.


All in all they way this plugin works is a great idea! The more 
it knows about the full commandline of the resulting dmd 
invocation, the more accurate it is.

[Issue 18013] DMD test suite assertion failure in test_cdvecfill.d

[d-bugmail--- via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||c...@dawg.eu,
   ||petar.p.ki...@gmail.com

--

Re: Precise GC state

[Ola Fosheim Grostad via Digitalmars-d]

On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky 
wrote:
Sadly you can’t “skip” write barriers in your @system code 
because it may run as part of larger @safe. Which is where they


Well, you can if you carefully lock the gc runtime or if you dont 
modify existing scannable pointers that points to existing 
objects (e.g. You could fill an empty array of pointers in unsafe 
code or pointers that point to something unscannable.), but all 
unsafe code would need vetting.


So it isnt impossible technically, but it is impossible without a 
change of philosophy.

Re: Precise GC state

[Dmitry Olshansky via Digitalmars-d]

On Sunday, 26 November 2017 at 04:01:31 UTC, jmh530 wrote:
On Friday, 24 November 2017 at 05:53:37 UTC, Dmitry Olshansky 
wrote:
A better GC is a great direction. Generational one is not 
feasible unless we disallow quite a few of our features.


What about @safe?


If all of the code is 100% @safe (not system and not trusted) you 
have a different language where write barriers would be cheaper 
to implement.


Sadly you can’t “skip” write barriers in your @system code 
because it may run as part of larger @safe. Which is where they 
are the most costly.

Re: .NET introduces Span, basically D slices

[Ola Fosheim Grostad via Digitalmars-d]

On Sunday, 26 November 2017 at 05:36:15 UTC, Guy wrote:
It's funny you say that because they just announced the 
introduction of ranges and I believe they return Spans.


Well, basic dataflow pipelines with implicit transfer of buffer 
ownership. So it is a language feature with implicit RAII 
lifetime management, which is why Span is limited to the stack. 
Then they have a counterpart to Span called Memory that can be 
stored on th GC heap.


A reasonable tradeoff, but a general constraint would have been 
more interesting.