The progress of D since 2013

[Maxim Fomin via Digitalmars-d]

Hi!

Good to see D is progressing! I was active forum and bugzilla 
participant in 2011-2013. Since then I have not touched D.


What is the progress of D (2014-2017) in following dimensions:
1) Support of linking in win64? AFAIK Walter introduced win64 
support in circa 2012 which was the big progress. However, 
support for win64 linking was limited because dmd defaulted on 
old dmc linker, and Walter didn't plan to do anything with this.
2) What is the support of other platforms? AFAIK there was 
progress on Android. From my memory recollections, the full 
support of Android was expected at that time.
3) What is the state of GC? AFAIK there were some improvements 
for GC sent as GSOC projects but they were not added in 2013. I 
see in the changelog that there are some improvements in speed 
and configuration support was added.
4) What is the state of GDC/LDC? GDC team was actively working on 
including gdc in gcc project. Do gdc and ldc still pull D 
frontend, so there is essentially 1 frontend (where gdc and ldc 
frontends lag several versions behind) + 3 backends? I see in the 
changelog some dmd backend improvements. How the dmd backend is 
compared with C++/GDC/LDC? AFAIK in 2013 there was a tradeoff: 
either you use dmd with brand-new frontend or gdc/ldc where 
performance is comparable to gcc, but frontend lags behind. Is it 
still true?
5) What is the progress with CTFE? I see a lot of discussions in 
forum archive devoted to the development of CTFE. What is the 
summary of CTFE development in recent years?
6) I don't see any significant changes in D core from dlang 
documentation (except those mentioned in changelog for 
2014-2017). Is is true or is the official spec as usual delayed 
:)? Is dlang spec fully and frequently updated or is it sparse as 
in the past? Is TDPL book still relevant?
7) Is UDA still compile-time? Are there plans to make it also 
runtime?
8) What is the progress with shared and immutable? AFAIK the 
compiler support for shared was not complete and Phobos library 
itself was not 'immutable-' and 'shared-correct'.

9) Does D gains popularity?
10) Anything else 2013 D user must know? :) I don't ask about 
Phobos because according to the changelog the progress is 
enormous, incremential and targets several directions - I doubt 
it can be easily summarised...


Thanks!

Re: char[] == null

[Maxim Fomin via Digitalmars-d-learn]

On Thursday, 19 November 2015 at 15:36:44 UTC, Steven 
Schveighoffer wrote:
On 11/19/15 3:30 AM, Jonathan M Davis via Digitalmars-d-learn 
wrote:
On Wednesday, November 18, 2015 22:15:19 anonymous via 
Digitalmars-d-learn wrote:

On 18.11.2015 22:02, rsw0x wrote:

slices aren't arrays
http://dlang.org/d-array-article.html


The language reference/specification [1] uses the term 
"dynamic array"
for T[] types. Let's not enforce a slang that's different 
from that.



[1] http://dlang.org/arrays.html


Exactly. T[] _is_ a dynamic array. Steven's otherwise 
wonderful article on
arrays in D ( http://dlang.org/d-array-article.html ) made the 
mistake of
calling the buffer that T[] points to on the GC heap (assuming 
that even
does point to the GC heap) the dynamic array. And per the 
language spec,

that's not true at all.


It was not a mistake :) It's how I still think of it. The spec 
is confusing, and my terminology, IMO, is a much more 
consistent (and accurate) way to think of it.


-Steve


Why formal definition of dynamic array caused confusion and is 
inconsistent? It is well consistent with static array and other 
aggregate types notions.


Consider this:

int *x = new int; // this is 'int type' ans it is 'dynamic'
int y;
int *a = // and this is not 'int type'

The problem is treating chunk of heap memory as some kind of type 
(dynamic in this case). Type of object determines an interface of 
interacting with object while storage determines memory location 
and possibly duration of lifetime. It is possible to have object 
of any type to be allocated on different storages - for example, 
slice does not necessarily points to dynamic array (in your 
terms). C and C++ established a long tradition of such standard 
notions as object, lifetime, storage and type. From system 
language perspective calling memory a type (in other words, type 
of object depends on where it was allocated) does not make much 
sense.

Re: Preventing implicit conversion

[Maxim Fomin via Digitalmars-d-learn]

On Wednesday, 4 November 2015 at 21:22:04 UTC, ixid wrote:
On Wednesday, 4 November 2015 at 19:09:42 UTC, Maxim Fomin 
wrote:

On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote:
Is there an elegant way of avoiding implicit conversion to 
int when you're using shorter types?


Only with library solution. Implicit conversions are built 
into language.


Doesn't that seem rather limiting and unnecessary?


Well, indeed it often produces confusion (this is inherited from 
C for compatibility purpose).

Re: Preventing implicit conversion

[Maxim Fomin via Digitalmars-d-learn]

On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote:
Is there an elegant way of avoiding implicit conversion to int 
when you're using shorter types?


Only with library solution. Implicit conversions are built into 
language.

Re: Overloading an imported function

[Maxim Fomin via Digitalmars-d-learn]

On Wednesday, 21 October 2015 at 12:05:27 UTC, Shriramana Sharma 
wrote:

import std.math;
real round(real val, int prec)
{
real pow = 10 ^^ prec;
return round(val * pow) / pow;
}

Trying to compile this I get:

foo.d(5): Error: function foo.round (real val, int prec) is not 
callable using argument types (real)


When I've imported std.math which contains round(real), why is 
the compiler complaining about not being able to call the 
overload function defined in *this* module?


I don't see anything in http://dlang.org/module.html that says 
I cannot define an overload of an imported function. Did I miss 
something?


My guess is that .round shadows math.round. But you can 
get desired behavior
by moving declaration of math.round inside scope of 
.round. This compiles:


real round(real val, int prec)
{
import std.math;
real pow = 10 ^^ prec;
return round(val * pow) / pow;
}

Re: Array of subclasses

[Maxim Fomin via Digitalmars-d-learn]

On Thursday, 22 October 2015 at 13:29:06 UTC, DarkRiDDeR wrote:


I don't need the base class data. How to create a array of 
subclasses objects with the derived data members?


The language is implemented in this way. You have already have 
the answer:



writeln(Core.users.name)
Out:
USERS

Re: Array of subclasses

[Maxim Fomin via Digitalmars-d-learn]

On Thursday, 22 October 2015 at 11:02:05 UTC, DarkRiDDeR wrote:


This variant works strangely. Example:

abstract class Addon
{
public string name = "0";
}
class Users: Addon
{
override
{
public string name = "USERS";
}
}
static final class Core
{
static:
public Addon[] activated;
public Users users;

public void activate()
{
users = new Users;
activated = [new Users, new Users];
}
}

Core.activate();
writeln(Core.users.name ~ "\n"  ~ Core.activated[1].name);

Out:
USERS
0


First of all, the code does not compile with override. It is 
impossible to override a data. Override should be removed.
The reason it works this way is that the first access is to base 
class data while the second is to the derived data member.

Re: Implicit conversion rules

[Maxim Fomin via Digitalmars-d-learn]

On Wednesday, 21 October 2015 at 19:49:35 UTC, Ali Çehreli wrote:

On 10/21/2015 12:37 PM, Sigg wrote:

> cause at least few more "fun" side effects.

One of those side effects would be function calls binding 
silently to another overload:


void foo(bool){/* ... */}
void foo(int) {/* ... */}

  auto a = 0;  // If the type were deduced by the value,
  foo(a);  // then this would be a call to foo(bool)...
   // until someone changed the value to 2. :)

Ali


Actually 'a' is deduced to be int, so int version is called (as 
expected?). See my example above for the VRO overload issue.

Re: Implicit conversion rules

[Maxim Fomin via Digitalmars-d-learn]

On Wednesday, 21 October 2015 at 22:49:16 UTC, Marco Leise wrote:

Am Wed, 21 Oct 2015 12:49:35 -0700
schrieb Ali Çehreli :


On 10/21/2015 12:37 PM, Sigg wrote:

 > cause at least few more "fun" side effects.

One of those side effects would be function calls binding 
silently to another overload:


void foo(bool){/* ... */}
void foo(int) {/* ... */}

   auto a = 0;  // If the type were deduced by the value,
   foo(a);  // then this would be a call to foo(bool)...
// until someone changed the value to 2. :)

Ali


God forbid anyone implement such nonsense into D !
That would be the last thing we need that we cannot rely on
the overload resolution any more. It would be as if making 'a'
const would change the overload resolution when none of the
overloads deal with constness...



AFAIK it was implemented long time ago and discussed last time 
couple of years ago with example similar to Ali's.


void foo(bool)
void foo(int)

foo(0); // bool
foo(1); // bool
foo(2); // int

Re: Moving back to .NET

[Maxim Fomin via Digitalmars-d]

On Tuesday, 22 September 2015 at 06:03:25 UTC, Laeeth Isharc 
wrote:

On Monday, 21 September 2015 at 19:15:28 UTC, Maxim Fomin wrote:

OK, the frustration is understandable. D is good enough to 
impress in short-run but has problems damaging itself in the 
long run. This leads to impression -> frustration cycle.


Well, that may or may not be true.  But someone who finds the 
error messages offputting isn't a good exemplar of putative 
deficiencies that show up in the long run, because these are 
part of the initial learning curve and after a year or two or 
experience it's really unlikely to be a main factor in 
determining choice of framework.  Whereas it's understandable 
that in the beginning it can be a big source of frustration.


I do not consider error messages as long run issue (it is 
discussed in the thread and I didn't mentioned it, so it might 
caused impression that I agree with complains about error 
messages).


And if you leave the Microsoft ecosystem, I am not sure that D 
fares so badly in relation to a certain C family language that 
has had a big influence.


If Microsoft ecosystem is left out then my opinion regarding 
comparison with Microsoft system is obviously irrelevant. 
Comparing with other languages I found D is decently good.




He didn't say how long he had been using D for, but as others 
point out one underestimates how much one knows in relation to 
existing languages, and forgets that it is a degree of work 
over months and years to learn something new...


I always could not understand complaints regarding D hard 
learning curve for anyone with C/C++/C# background.




Either you need portability and you care what Mono does, or 
you don't.
Commercial decisions are often a matter of tradeoffs.  Eg for 
internal enterprise software you might find it valuable to be 
able to run on both linux and windows, but you can always make 
it a service on windows if linux is too much trouble.


Sounds like 'lazy' portability: if app is portable - than good, 
if not - ok, we can leave with it:)

Re: Moving back to .NET

[Maxim Fomin via Digitalmars-d]

On Tuesday, 22 September 2015 at 17:43:59 UTC, Maxim Fomin wrote:

On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:


Sure, but in many cases D allows you to work around decisions 
you don't like. Plus, you can actively contribute, make 
suggestions and prove your case. The length of some threads 
shows that Walter, Andrei and others involved in the 
development take input seriously and answer questions and give 
the reasons for their decisions.


Well, in case of C/C++ there is also rationale for decision, 
but not in the forum form. But providing rationale is not 
helpful if there is disagreement.




To elaborate. If the issue is comparing chances of changing 
language in a user-oriented way of D and standardized languages, 
then it is definitely no. First of all, there is huge information 
gap between language hackers and users. Secondly, it is hard to 
beat the 'committee' argumentation even if they are wrong - they 
are simply to skilled and experienced.


Two examples. I am aware of only one case when Walter and Andrei 
agreed with community. It is epic bugzilla discussion [1] 
regarding contract programming. It took 60 comments to convince.


[1] https://issues.dlang.org/show_bug.cgi?id=6857

The second example is more recent dmd pull discussion regarding 
template linkage behavior (Walter + Martin vs. Kenji). After long 
discussion the outcome was that some rare but used feature was 
dropped for the sake of dmd internals convenience. Walter's 
argumentation was that the language feature was working by 
chance, so relying on it is a mistake (to be more precise, the 
question was whether to write new code to support feature in 
another context or to drop it and make code cleaner). After new 
release there were couple issues filed in bugzilla that 
complained about new behavior, but were closed as invalid (sorry, 
don't have link, recollect from memory).


So, my point is that D except communication channel is pretty 
much the same as standardized languages with respect to changing 
language. I would say there are better chances that some feature 
will suddenly be changed and backfire existing code rather than 
user will convince to tweak the existing features to make it user 
- friendly at the expense of internals complexity. I do admit 
that discussions of new features and simple enhancements provide 
better chances (discussion is about significant issues, not 
trivial enhancements - isn't it?).

Re: Moving back to .NET

[Maxim Fomin via Digitalmars-d]

On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:
On Tuesday, 22 September 2015 at 11:44:35 UTC, Maxim Fomin 
wrote:

On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:


to be confined by committee decisions etc.,


D has committee (Walter & Andrei). Some of their decisions 
frustrate D users too.


Sure, but in many cases D allows you to work around decisions 
you don't like. Plus, you can actively contribute, make 
suggestions and prove your case. The length of some threads 
shows that Walter, Andrei and others involved in the 
development take input seriously and answer questions and give 
the reasons for their decisions.


Well, in case of C/C++ there is also rationale for decision, but 
not in the forum form. But providing rationale is not helpful if 
there is disagreement.


That these decisions are not always to everyone's liking is 
inevitable. Given the contradictory nature of requirements in 
programming, it's only logical that one cannot cater for both 
sides all the time.


Definitely agree.

Re: Moving back to .NET

[Maxim Fomin via Digitalmars-d]

On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:


to be confined by committee decisions etc.,


D has committee (Walter & Andrei). Some of their decisions 
frustrate D users too.

Re: Moving back to .NET

[Maxim Fomin via Digitalmars-d]

On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:

My experiences with D recently have not been fun.
...
My main concern with .NET is portability and performance. I am 
going to give in to the portability and just assume Mono is 
good enough. Performance wise, I'd prefer D, but .NET is 
performant enough for most apps. Maybe in a few years things 
will change, I can't wait that long. Sorry guys! (not that you 
will miss me)


OK, the frustration is understandable. D is good enough to 
impress in short-run but has problems damaging itself in the long 
run. This leads to impression -> frustration cycle.


However, one point regarding portability. It is wrong to target 
cross - platform project by *assuming* that Mono is good enough. 
Either you need portability and you care what Mono does, or you 
don't. But then it is irrelevant what happens in Linux.


By the way, it seems you started from .Net from the very 
beginning. It is unclear why you considered D in such 
circumstances (of course, except portability, but it seems you 
actually don't need it).


Last point. You mentioned performance. Did you run benchmarks?

Re: D for Game Development

[Maxim Fomin via Digitalmars-d]

On Tuesday, 4 August 2015 at 19:14:51 UTC, Rick wrote:


After leaving C++ behind for a few years to work in some 
higher-level languages for job-related coding, I was excited 
when I stumbled upon D ...


This is a typical path ...

I spent several weeks tearing through the language reference 
and standard APIs ...




... of a new user, who becomes very impressed

Unfortunately I'm regrettably having to reconsider my decision 
to start a game project (or any project requiring significant 
time investment) in D.


... but the story usually continues with disillusionment
(let me guess: buggy toolchain, not everything is ready)

Not because of the language or compiler, but rather because of 
the lack maturity in the supporting tools; specifically, a 
debugger.


Yep.

Re: how come is this legal? 'void fun(int){ }' ?

[Maxim Fomin via Digitalmars-d-learn]

On Sunday, 14 June 2015 at 01:20:39 UTC, Timothee Cour wrote:
I understand this is legal for declaration wo definition (void 
fun(int);)

but why allow this:
void test(int){} ?


Actually it is void test(int _param_0) { }
You can test by compiling void test(int) { _param_0 = 0; }

Nameless parameters are simulated by providing internal symbol as 
above.

Re: Thoughts about the ideal programming language

[Maxim Fomin via Digitalmars-d]

On Wednesday, 13 May 2015 at 18:59:42 UTC, Dennis Ritchie wrote:

Hi,
I think that many will find something interesting in this 
article:

-
https://translate.google.ru/translate?hl=rusl=rutl=enu=http%3A%2F%2Fhabrahabr.ru%2Fpost%2F257875%2F
-
Sorry translated using google translate.


Can few to say regarding your thoughts, but need to mention that 
that site is the only significant one I am aware of with 
anti-technical, inflated, self - important culture of discussion 
(this has nothing to do with your post particular).

Re: Cannot Qualify Variadic Functions with Lazy Arguments as nothrow

[Maxim Fomin via Digitalmars-d-learn]

On Thursday, 14 May 2015 at 09:53:20 UTC, Per Nordlöw wrote:

At

https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L43

I've implemented a function either() with behaviour similar to 
the `or` function/operator in dynamic languages such as Python 
and Lisp.


I'm almost satisified with it except that the lazy evaluation at

https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L45

cannot be made nothrow.

If I qualify the function as nothrow DMD complains as

algorithm_ex.d(45,16): Error: 'a' is not nothrow
algorithm_ex.d(46,29): Error: '_param_1' is not nothrow

I don't see a reason why any of these two cases should throw.


Lazy argument is essentially delegate/function. Currently there 
is no

way to mark it as nothrow.

The same problem occurs if I make the implementation use only 
one function and check the recursion termination case with 
`static if (bs.length == 1)` instead.


Is there a workaround for this?


One way to address is to use delegate explicitly.

int foo(lazy int a) //nothrow
{
return a;
}

int bar(int delegate() nothrow dg) nothrow
{
return dg();
}

void main() nothrow
{
int a;
bar(()=a);
}

Re: D casually mentioned and dismissed + a suggestion

[Maxim Fomin via Digitalmars-d]

On Wednesday, 13 May 2015 at 09:20:36 UTC, Bienlein wrote:
You are making a cool project and we'd like to contribute to 
it, but we don't know and neither feel like studying this silly 
D.


This is indeed a problem for many newly created languages. 
Scala has somewhat managed to create its own eco system with 
Akka, Spark, Spray in a specialized area like concurrent 
programming and big data. Also because Scala has found some 
liking in academical circles (e.g. Spark, Scala STM). I don't 
know how things will look like for Kotlin. Maybe there will be 
a niche for Android development. For Groovy there is basically 
only Grails as a killer application.


Giving how D is similar to C/C++ I am surprised that 
non-familiriarity with D is a big problem.

Re: UDAs and no complaints about need 'this'

[Maxim Fomin via Digitalmars-d]

On Thursday, 9 April 2015 at 09:53:15 UTC, John Colvin wrote:

struct BigLongStructName
{
int evenLongerMemberName;
}

struct QN{}

unittest
{
BigLongStructName bigLongStructName;

@(bigLongStructName.evenLongerMemberName)
QN quickName;

__traits(getAttributes, quickName)[0]++;
}

Is it just me or is it weird that this works? Once you pull the 
UDA out from being a storage class and attempt to alias it, you 
get the usual need 'this' for 'evenLongerMemberName' of type 
'int' error messages on use.


Why are UDAs so special? I don't believe there's any other way 
to achieve this sort of effective renaming.


For me it seems to fit into D type system (which is not 
necessarily is a good idea).


struct S
{
int i;
}

alias S.i si;

void main(){ /*si++;*/}

Behavior of D depends sometimes on it internals, not on 
programmers' expectations. Since D has never been stabilized, the 
boundary between WAT and bugs is partially undefined.

Re: size_t for length on x64 will make app slower than on x86?

[Maxim Fomin via Digitalmars-d]

On Sunday, 16 November 2014 at 13:39:24 UTC, FrankLike wrote:
Many old projects need move from x86 to x64,but the 'length' 
type is size_t,it will change on x64,so a lot of work must to 
do.but I find some info which is help for d:

http://www.dotnetperls.com/array-length.
it means:
  test length and longlength, and found 'test longlength' is  
slower than 'test length'.


  0.64 ns   Length
  2.55 ns   LongLength

I love D.So I don't want my app on x64 slower than on x86.

Hope change in 2.067.

Thank you all.


It means where you have uint x = arr.length you should have had 
size_t x = arr.length from the very beginning.

Re: DMD v2.066.0-rc1

[Maxim Fomin via Digitalmars-d-announce]

On Thursday, 31 July 2014 at 12:51:53 UTC, Andrew Edwards wrote:

DMD v2.066.0-rc1 binaries are available for testing:

http://wiki.dlang.org/Beta_Testing


What about changelog?

http://dlang.org/changelog.html

In past it was pretty nicely made, but now it lists only 2 
changes (unlike 2.065 and 2.064 comprehensive changelogs and 
judging by how much time passed since 2.065 it should be lengthy 
too).

errno_c.obj in druntime

[Maxim Fomin via Digitalmars-d]

Currently I am building dmd on win64. For some reason some phobos 
code references getErrno() function in errno_c.obj and that 
object file is not included into final binary (linker issues 
symbol absence error - by the way I don't remember it was needed 
on linux). It can be avoided by adding file into linking list, 
however it is only x86 version and during building win64 linker 
issues error due to model mismatch.


1) Why two trivial functions should be placed into separate .c 
file compounding win64 buildings headache instead of placing it 
somewhere in druntime among other D code?


2) How to avoid it? It comes to my mind to write two functions in 
D, compile with -m64 -c, replace x86 version with x64 version, 
add to gitignore, but then there would be repo syncing issues. 
Anyway it seems to be a too strange way to build a project.


P.S.
What's so wrong with D on win64? I had nothing close to win64 
building difficulties when was dealing with linux x64 or x86.

Re: Can't modify this

[Maxim Fomin via Digitalmars-d-learn]

On Saturday, 28 June 2014 at 20:40:21 UTC, Ary Borenszweig wrote:

This doesn't work:

class Foo {
  this() {
this = new Foo;
  }
}

Error: Cannot modify 'this'

However you can do this:

class Foo {
  this() {
auto p = this;
*p = new Foo();
  }
}

It even changes the value of this!

Should that compile? I mean, it's the same as modifying 
'this'...


D language was not aimed toward preventing any attepmt to 
circumvent some hypothetical limitations (it does not even cope 
with things which it should definetely prevent). There are holes 
much - much worse. And changing value of this parameter is not a 
problem anyway, since it is possible to have typeid(this) != 
typeid of type of current method which is bigger problem than 
pointing to different value of same type.

Re: Constant relationships between non-constant objects

[Maxim Fomin via Digitalmars-d]

On Wednesday, 18 June 2014 at 05:34:18 UTC, Sebastian Unger wrote:


So again, I believe, if D wants to play any role in major OO 
software design and development, it will need to step up its 
game. Especially in view of C++11 having addressed a number of 
the issues in C++ that I would have chosen D over C++ for.


Cheers,
Seb


I believe this is wrong. First of all, if you want to keep 
relationship between objects, instead of thinking which feature 
can prevent it, consider not to try to break it in a first place.


Secondly, it is sometimes discussed how to write some idiomatic 
code per se, rather than to solve particular task.


Thirdly, if feature from one language does not do the same as 
similar feature from other language, does not mean that the 
feature/language is broken.


Lastly, taking into account that it was Walter decided to do so, 
says something.


Regarding your problem. Keeping relationship between two classes 
can be achieved by associative array, by inheriting from one 
class or by using examples above.

Re: Unnamed parameter with default value

[Maxim Fomin via Digitalmars-d]

On Tuesday, 17 June 2014 at 15:15:44 UTC, Luís Marques wrote:

Is there any particular reason why this is accepted? (I
introduced it by mistake):

 void foo(int = 3) {}

I guess it could be useful to ensure binary compatibility when
you expect to add the parameter later?


Actually there is nothing strange because current implementation 
technically does not remove variable names, it generates implicit 
ones. This compiles:


void foo(int = 0)
{
_param_0 = 1;
}

and is equivalent to

void foo(int _param_0 = 0)
{
_param_0 = 1;
}

It is not a wise design decision which is aimed to support some 
case, it is just technical consequence of implementation.


And I don't think that it has anything to do with binary 
compatibility, because both parameter names and default arguments 
exists only in compile time.

Re: Tail pad optimization, cache friendlyness and C++ interrop

[Maxim Fomin via Digitalmars-d]

On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote:

On 6/11/2014 4:34 AM, Timon Gehr wrote:
Not memory safe implies (is supposed to imply) not @safe but 
not @safe does not

imply not memory safe.


@safe in D == memory safe.


Why? I found dozens of cases when @safe is broken, let alone 
other issues in bugzilla.


After thinking about the @safety in D my conclusion is that it is 
impossible to evaluate memory and safety correctness of a code in 
which static type says nothing about where an object is 
allocated. Contrary to popular wisdom, one can have fixed array 
on heaps, classes on stack, etc. If any code which is potentially 
not safe is rejected, this would lead to lots of false positives 
making using the language very inconvenient. Even in that case, 
safety cannot be guaranteed by the language due to other issues, 
like separate compilation, etc. By the way, memory safety is also 
compromised by compiler bugs which make him generate buggy code. 
Note, when I counted memory safety problems, codegen issues were 
not counted.


@safe should not be considered as feature which ensures that the 
code is memory safe, but as a feature rejecting code with high 
probability of memory bugs. The difference is very important.


I have reached this conclusion some years ago and nothing has 
change in D since then which make me reconsidering my opinion 
(including that @safe holes were not fixed).


Note, that I do not critique the language, it is fine. It is very 
good system level language with powerful modelling features. It 
is not good at verifying memory correctness, because in such 
languages (unlike managed ones) burden of memory correctness lies 
mostly on programmer. If he thinks that he can outsource memory 
correctness to @safe, there is high probability that he would be 
suddenly surprised.

Re: Why are breakpoints caught by the runtime?

[Maxim Fomin via Digitalmars-d]

On Sunday, 15 June 2014 at 15:23:29 UTC, Marc Schütz wrote:

On Sunday, 15 June 2014 at 14:50:30 UTC, Trass3r wrote:

void main()
{
asm { int 3; }
}

object.Error: Breakpoint

0x00402013 in _Dmain at bptest.d(6)
0x00402314 in void rt.dmain2._d_run_main(int, char**, extern 
(C) int function(char[][])*).runAll().void __lambda1()
0x004022E7 in void rt.dmain2._d_run_main(int, char**, extern 
(C) int function(char[][])*).runAll()

0x00402200 in _d_run_main


Is there any good reason to catch that?
I really want the debugger to fire up.


Which OS and compiler version is that? The breakpoint is 
correctly triggered here on openSUSE 13.1 x86_64 / DMD 2.066 
git:


# ./bptest
Trace/breakpoint trap
# gdb ./bptest
...
(gdb) run
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0041b7b5 in D main ()
(gdb)


Obviously he is using windows and compiler version is irrelevant 
-  it is windows runtime issue.

Re: Why are breakpoints caught by the runtime?

[Maxim Fomin via Digitalmars-d]

On Sunday, 15 June 2014 at 14:50:30 UTC, Trass3r wrote:

void main()
{
asm { int 3; }
}

object.Error: Breakpoint

0x00402013 in _Dmain at bptest.d(6)
0x00402314 in void rt.dmain2._d_run_main(int, char**, extern 
(C) int function(char[][])*).runAll().void __lambda1()
0x004022E7 in void rt.dmain2._d_run_main(int, char**, extern 
(C) int function(char[][])*).runAll()

0x00402200 in _d_run_main


Is there any good reason to catch that?
I really want the debugger to fire up.


It is default windows runtime behavior and unless it provides 
some interface to adjust it, you can not fix it (except patching 
and rebuilding runtime, of course). Or, perhaps, you can bypass 
runtime behavior by using windows api directly to adjust the 
behavior to your needs.


By the way, judging by that runtime catches windows exceptions 
and rethrows them as errors (object.Error: Breakpoint), you are 
not encouraged to catch them.

Re: Null pointer dereferencing in D

[Maxim Fomin via Digitalmars-d]

On Saturday, 14 June 2014 at 12:33:28 UTC, Dicebot wrote:

On Saturday, 14 June 2014 at 10:15:49 UTC, Marc Schütz wrote:
Huh? Types with `@disable this()` still have an `init` value. 
All it does is disallow instantiating the type without 
specifying an initializer (e.g. a struct literal, a value 
returned from a factory function, or `static opCall()`).


Which is effectively a type system hole with @disable this :

struct A { @disable this(); }
auto a = A.init;


Why this is a type hole if initializer is explicitly provided?

The idea of disabled this() is to prevent default initialization,
not to reject potentially buggy one.

Re: Null pointer dereferencing in D

[Maxim Fomin via Digitalmars-d]

On Saturday, 14 June 2014 at 14:51:10 UTC, Dicebot wrote:

On Saturday, 14 June 2014 at 13:38:40 UTC, Maxim Fomin wrote:

Which is effectively a type system hole with @disable this :

struct A { @disable this(); }
auto a = A.init;


Why this is a type hole if initializer is explicitly provided?

The idea of disabled this() is to prevent default 
initialization,

not to reject potentially buggy one.


Well consider imaginary NotNullable struct that uses @disable 
this() to guarantee that instance of that struct always has 
meaningful state. By using (NotNullable!T).init you can get 
value of that type which is in fact null and pass it as an 
argument to function that expects NotNullable to always be non 
null. With no casts involved you have just circumvented 
guarantees static type system was suppose to give.


You can complain if language itself produces code which accesses 
init property. This would be violation of disable premise. 
However, it is clearly you who intentionally asked init property, 
so there is no language fault here.


For example, some time ago implicit disable struct creation 
issues (in context of array copy, out parameter, etc. ) were 
filed and fixed. If you face situation when compiler generates 
default disabled struct without user permission, this would be a 
bug.


The case which you described is a not a type safety problem. 
There is no reinterpretation of object of one type as another 
type (or reading/writing memory which should not have been 
read/written). It is perfectly safe to assign object of type A to 
the same type. What is presented is some sort of design pattern 
violated by the user, not the language (and the goal of the 
pattern cannot be fully achieved in D language).

Re: Null pointer dereferencing in D

[Maxim Fomin via Digitalmars-d]

On Saturday, 14 June 2014 at 15:41:10 UTC, John Colvin wrote:

On Saturday, 14 June 2014 at 14:51:10 UTC, Dicebot wrote:

On Saturday, 14 June 2014 at 13:38:40 UTC, Maxim Fomin wrote:

Which is effectively a type system hole with @disable this :

struct A { @disable this(); }
auto a = A.init;


Why this is a type hole if initializer is explicitly provided?

The idea of disabled this() is to prevent default 
initialization,

not to reject potentially buggy one.


Well consider imaginary NotNullable struct that uses @disable 
this() to guarantee that instance of that struct always has 
meaningful state. By using (NotNullable!T).init you can get 
value of that type which is in fact null and pass it as an 
argument to function that expects NotNullable to always be non 
null. With no casts involved you have just circumvented 
guarantees static type system was suppose to give.


Hole in the type system: yes
Necessarily a bad thing: no


It depends on what do you mean by type safety. If commonly 
accepted definition is chosen (for example, what type safety 
article means), than there is no type safety problem here.


Some data-types require runtime initialisation to be valid. By 
using .init you are explicitly circumventing any runtime 
initialisation. It's an explicit hole, just like cast.


Yes, this is known. But note, that it is user, not the language, 
who
circumvents initialization. By the way, what many people expect 
from the feature - to have reference which points to 
preallocated, valid object is hardly achievable in system level 
language where due to free access to memory and memory bugs 
reference may hold any value. For example, class object may turn 
into integer with value 12345.


class A {}
int I = 12345;
A a = cast(A) I;

With the same reasoning I can say that language is faulting here 
because it allowed for me to circumvent my own wishful(!) 
assumption that references should always be allocated and point 
to valid memory.


The fact that pointer or reference can be null, is a tiny, tiny 
problem. You can test for null, but you cannot check whether 
pointer contains valid address. For example, try to figure out 
whether it is safe to write to address 0xFEFFABCD in some 
particular context.


It appears that it possible (in 2.065 at least) for a struct to 
provide it's own init, which can of course be


template init() { static assert(false); }

Is the ability to manually specify .init a bug or a feature? I 
feel like it's a bug.




As far as I remember the ability to define init property was 
since 2.058. The semantic would that if you access init 
explicitly, you would get overridden property, but in other cases 
(for example allocation) the semantic is of language init. 
Probably it was filed as a bug, I don't remember.

Re: Null pointer dereferencing in D

[Maxim Fomin via Digitalmars-d]

On Saturday, 14 June 2014 at 17:05:21 UTC, David Nadlinger wrote:

On Saturday, 14 June 2014 at 16:45:19 UTC, Maxim Fomin wrote:

The case which you described is a not a type safety problem.


If a struct type has a non-trivial invariant(), .init allows an 
object to exist that violates it without an Error being thrown.


Arguing that this is not part of the type system would be 
splitting hairs.


David


Again, it may depend on your definition of type safety. In my 
view, it is not related. It is a problem of unwarranted 
assumption about data correctness in a system level language.


By the way, AFAIK the issue has been already filed in bugzilla 
(closed as wontfix) and discussed in newsgroups. After the 
discussion the spec was updated to explicitly mention that init 
property may be problematic http://dlang.org/property.html 
(please notice, that invariant example is in the spec). Another 
issue which popped up is that in order to fix disable this() init 
problem, one need to break assumption about init availability in 
compile time, which breaks CTFE. In other words, it is impossible 
to fix the issue without creating a multitude of new problems.

Re: Null pointer dereferencing in D

[Maxim Fomin via Digitalmars-d]

On Saturday, 14 June 2014 at 17:05:21 UTC, David Nadlinger wrote:

On Saturday, 14 June 2014 at 16:45:19 UTC, Maxim Fomin wrote:

The case which you described is a not a type safety problem.


If a struct type has a non-trivial invariant(), .init allows an 
object to exist that violates it without an Error being thrown.


Arguing that this is not part of the type system would be 
splitting hairs.


David


Déjà vu

http://forum.dlang.org/thread/mohceehplxdhsdllx...@forum.dlang.org#post-mailman.550.1349377293.5162.digitalmars-d:40puremagic.com

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

If I not mistaken it was Kenji who updated the init spec.