On Tuesday, 7 June 2016 at 06:30:05 UTC, ketmar wrote:
> On Tuesday, 7 June 2016 at 06:22:50 UTC, Walter Bright wrote:
>> On 6/6/2016 10:38 PM, Brad Roberts via Digitalmars-d wrote:
>>> The D ecosystem is a large pile of incomplete features, with more added all the
>>> time.
>>
>> Even with only array bounds checking, D is safer than C++.
>
> +inf. this feature alone made me much more productive, and took away alot of pain. (dreaming) if only RangeError could show invalid index too...

^ Thats my biggest beef with it, too. Error messages should contain as much detail as is reasonable for the operation. As an aside, I remember Adam did a PR/Bug submission or something and it was argued that it would add too much bloat(??)

Heres to hoping we get that at some point.

On Tuesday, 7 June 2016 at 06:22:50 UTC, Walter Bright wrote:
> On 6/6/2016 10:38 PM, Brad Roberts via Digitalmars-d wrote:
>> The D ecosystem is a large pile of incomplete features, with more added all the
>> time.
>
> Even with only array bounds checking, D is safer than C++.

Better doesn't matter. So good that it justify the switch do matter, anything less is worthless.

On 6/6/2016 11:22 PM, Walter Bright via Digitalmars-d wrote:
> On 6/6/2016 10:38 PM, Brad Roberts via Digitalmars-d wrote:
>> The D ecosystem is a large pile of incomplete features, with more
>> added all the
>> time.
>
> Even with only array bounds checking, D is safer than C++.

Nice deflection, has the benefit of being both correct and irrelevant.

Yes, bounds checking is great.  Yes, D is safer than C++, but we were talking about @safe as a specific, advertised, but low-priority and largely unrealized feature, not the general safety of the language. @safe is intended to be a big leap forward, but falls flat outside toys.

I want the protections it's intended to bring.  I want the notification I've accidentally violated one of the rules.  I want the productivity gains from not having to debug cases it's intended to catch.

This minimization and deflection of real user feedback is rather disappointing and somewhat insulting.  Instead, I'd prefer to see acceptance that it's an actual issue and not hand waved away as not really a problem of current, real, users.

Sigh,
Brad

On Tuesday, 7 June 2016 at 05:38:25 UTC, H. S. Teoh wrote:
> A Decimal type isn't hard to implement as a user-defined type. I don't understand the obsession with some people that something must be a built-in type to be acceptable...

As I see it, any kind of an implementation that's comparable to what's out there is acceptable, be it a standard libary or user library, as long as it's visible and people can easily find it.

For example in C++ land: https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library/

Which makes a point of stating it conforms to standards and is usable in cases where decimal is legally required.

And in C# land: https://msdn.microsoft.com/en-us/library/system.decimal(v=vs.110).aspx

System.Decimal and the basic decimal type being a part of the .NET runtime/C# language.

Both are highly visible from Google searches.

On 6/6/2016 11:46 PM, deadalnix wrote:
> On Tuesday, 7 June 2016 at 06:22:50 UTC, Walter Bright wrote:
>> On 6/6/2016 10:38 PM, Brad Roberts via Digitalmars-d wrote:
>>> The D ecosystem is a large pile of incomplete features, with more added all the
>>> time.
>>
>> Even with only array bounds checking, D is safer than C++.
>
> Better doesn't matter. So good that it justify the switch do matter, anything
> less is worthless.

The context is someone using C++ for the sole reason that D has holes in @safe, and that doesn't make sense.

Granted, one can certainly have other reasons to prefer C++. But memory safety isn't one of them.

On Monday, 6 June 2016 at 02:20:52 UTC, Walter Bright wrote:
> Andrei posted this on another thread. I felt it deserved its own thread. It's very important.
> -----------------------------------------------------------------------------
> (...)
> * Documentation and tutorials are weak.

Regarding documentation, I'll just point out something that people seem not to understand here. I think the complaints about bad docs are not really about accuracy of what is displayed on the screen. I think accuracy is very good. They are more about usefulness and discoverability.
Its just the amount of cruft that a user has to go through to find out what exists and how he can apply it.

I'll pick on string documentation as an example. Other concepts will have different issues.

As a concrete example, how good is
https://docs.python.org/2/library/stdtypes.html#str.find
in comparison with
https://dlang.org/phobos/std_string.html#.indexOf
?

I think python version has several advantages:
- It is more conscise due to uniform handling of single char and string.
- It is more conscise due to not displaying a lot of pointless cruft that the user doesn't care about.
- It is more discoverable due to the name "find".
- It is more discoverable due to being a method of str type.

Problems with the D version are:
- There is heavy use UFCS, so things are split into different modules. String is an array, which means that UFCS must be used to extend it.
- The whole deal with dchar and unicode vocabulary all over the place, which adds to the amount of information. It would be much better to just assume correct Unicode handling and concentrate on how is a function different from other functions, as this is what user needs. Yes, details are good, but
- Strong typing in D has a lot of concepts that a newcomer has to learn before docs stop causing anxiety.
- The type constrains add visual noise.
- For the type constraints, it is hard to find what is the intention of their existence. It is typically not spelled out in English language.

Can something like this be made for the D version? I claim it can. We just have to drop the compulsion to document every detail and generate a simplified version of the docs.
I think such a simplified, python-like documentation could live as yet another version of docs that concentrates on usage rather than definition. It could contain links to the full version. :)

And, as a cherry on the cake, what is the first thing that user sees in the D version?
"Jump to: 2"
It is not readable at all. What is 2? Second what? What is the difference between the 2 things? I had to squint hard to find out (I wasn't lucky enough to read the first line of description first when I was finding out the difference. I started by looking at the function signatures). Those things should be described in english language somehow.

And regarding cheatsheets, as pointed out before, they don't work as a discoverability aid. You really need 2 or 3 sentences to tell what a fucntion does. A line of cryptic code that presents *one* data sample doesn't work.

On Tuesday, 7 June 2016 at 07:17:04 UTC, Walter Bright wrote:
> Granted, one can certainly have other reasons to prefer C++. But memory safety isn't one of them.

That's true, but memory safety isn't a big problem in C++ if one sticks to what one can do in @safe code. Using gsl::span you get the same stuff as in D for slicing etc.

In my experience memory issues in C++ often comes from casting through pointers  (which often is necessary for performance reasons) and having typos in pointer-offsets.

On Tuesday, 7 June 2016 at 05:52:33 UTC, ketmar wrote:
> On Tuesday, 7 June 2016 at 05:38:25 UTC, H. S. Teoh wrote:
>>
>> Same thing goes with a fixed point type. People keep complaining about it, but honestly if I were in the finance sector I'd implement the type myself in a couple o' days and put it up on code.dlang.org or something. It's not *that* hard.
>
> i've seen some implementations already (and, of course, made my own too). it is not that hard, and it working nice. so yes, i'm all for that. and literals of various custom types can be implemented with CTFE magic, like `octal!`, for example.

Well, it is a lot of work to get the base 10 IEEE 754-2008 implementation conformant. Fortunately IBM has already done it under a BSD license:

http://www.bytereef.org/mpdecimal/index.html

So all you base-10 dudes have to do is to translate it into D.

On Tuesday, 7 June 2016 at 05:38:09 UTC, Brad Roberts wrote:
> I've fixed some of the issues in a couple bursts of activity over the last several years, and filed a bunch more bugs, but the specifics aren't the point I'm raising here, though your trimming of the thread dropped that part of the context.  You dismissed complaints of the incompleteness of safety as the whining of non-users.  I'm a user.  I was a much more frequent user until I got tired of the sheer number of only partially complete nature of so much of the language + core library.  Yes they're separate, no that's not relevant to the majority of users.  Yes, I can and have contributed to the fixes, but it's clearly (just based on commit history) not a priority to many people.

Same here....

>
> The D ecosystem is a large pile of incomplete features, with more added all the time.

I'm not using D anymore, at least not for new production projects, exactly for that reason. I don't feel confident any more on the future of the language exactly for that reason.

/Paolo

On 6/7/2016 12:07 AM, Brad Roberts via Digitalmars-d wrote:
> Yes, D is safer than C++, but we were talking
> about @safe as a specific, advertised, but low-priority and largely unrealized
> feature, not the general safety of the language. @safe is intended to be a big
> leap forward, but falls flat outside toys.

I looked over the issues marked 'safe' in bugzilla, and do not understand the complaint that it falls flat and is largely unrealized. There are holes in it, sure, but they do not take away from what is covered, which is quite a bit.


> This minimization and deflection of real user feedback is rather disappointing
> and somewhat insulting.  Instead, I'd prefer to see acceptance that it's an
> actual issue and not hand waved away as not really a problem of current, real,
> users.

I cannot do anything with handwaving statements, whether I accept them and hang my head in shame or not. Although I may have missed some, or some may not be tagged properly, I found only one bugzilla issue from you tagged 'safe':

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

Here is the complete list of issues tagged with 'safe':

https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe&keywords_type=allwords&list_id=208819&query_format=advanced

Writing up specifically what problems you're having would be most appreciated.