On Tuesday, 7 June 2016 at 23:05:49 UTC, Walter Bright wrote:
> On 6/7/2016 2:28 PM, Steven Schveighoffer wrote:
>> I can attest that figuring out why something isn't inferred @safe isn't always
>> easy, and the "slap a @safe: tag at the top" isn't always going to help.
>
> Having a -safe compiler switch to make @safe the default won't improve that in the slightest.

I think it's useful here to compare one aspect of Perl's approach to
security, its "taint" mode.  It tags insecure data to make sure it
does not affect the security of the application, and blocks actions
where insecure actions would otherwise occur.  The Perl invocation
accepts a couple of flags to control how taint mode works:

  -t  Like -T, but taint checks will issue warnings rather than fatal
      errors.  These warnings can now be controlled normally with "no
      warnings qw(taint)".

      Note: This is not a substitute for "-T"! This is meant to be used
      only as a temporary development aid while securing legacy code:
      for real production code and for new secure code written from
      scratch, always use the real -T.

  -T  turns on "taint" so you can test them.  Ordinarily these checks
      are done only when running setuid or setgid.  It's a good idea to
      turn them on explicitly for programs that run on behalf of someone
      else whom you might not necessarily trust, such as CGI programs or
      any internet servers you might write in Perl.  See perlsec for
      details.  For security reasons, this option must be seen by Perl
      quite early; usually this means it must appear early on the
      command line or in the "#!" line for systems which support that
      construct.

The point being, such flags provide a very simple means for the user
to check the execution of their code, without being terribly intrusive.
They can be a great convenience as a stepstone to discovering where
problems exist and addressing them.

On 06/06/2016 04:15 AM, Russel Winder via Digitalmars-d wrote:
>
> 3. Have one lightweight D realized cross platform IDE. Qt us probably
> the best widget set to use for this. My model here is LiteIDE which is
> a Qt-based Go IDE realized in C++. It should of course be realized in
> Go, but there are no Qt bindings for Go, only QML ones.
>

One thing I've been really wanting to do for awhile (and even moreso after switching my main desktop to Linux) is take Programmer's Notepad 2 (a windows program, but very lightweight and very nice) and try porting it to D+Qt (or maybe libui if it gets a Qt backend). Although I don't know how realistic Qt on D in right now, and I haven't been able to justify the personal time & energy investment, even as much as I'd like to :( Just can't find a linux editor I like as much as PN2 :(

On Tuesday, 7 June 2016 at 08:09:49 UTC, Ethan Watson wrote:
> On Tuesday, 7 June 2016 at 07:57:09 UTC, Walter Bright wrote:
>> C++ still suffers from:
>>
>> http://www.digitalmars.com/articles/b44.html
>>
>> and probably always will.
>
> template< size_t size > void function( char ( &array )[ size ] );
>
> It's horrible syntax (no surprise), and being a templated function means it's recompiled N times... but there's at least something for it now.

There is array_view and string_view that have been proposed (and I even think  accepted) for C++17.

But if you want a fat pointer, you can just write one yourself:

template< typename T >
struct FatPtr
{
   template< std::size_t N >
   FatPtr( T (&a)[N] )
      : p (a)
      , n (N)
   { }

   T *p;
   std::size_t n;
};

void function( FatPtr<char> a );

int main( )
{
   char a[128];
   function(a);

   function("foo");
}

On 06/06/2016 09:15, Russel Winder via Digitalmars-d wrote:
>> * Tooling is immature and of poorer quality compared to the
>> > competition.
> This is true.
>
> We have too many half-finished attempt at things, basically because
> everything is volunteer, not directly associated with work, activity.
> Nothing wrong with this per se, but an obvious explanation why it is
> so. Unless an oirganization or seven put some work-oriented effort into
> the tooling, nothinkg will change.
>
> I would suggest three ways forward:
>
> 1. Get effort on the IntelliJ IDEA and CLion plugin. Kingsley has made
> a start. I suggest using his work as a basis and doing a new version
> written in Kotlin instead of Java. Kotlin will be easier than Java for
> D people to work with and easy for Java people to work with.
>
> 2. Get effort on the DDT Eclipse plugin. Bruno has declared it
> finished, which is fine, but I would say it should not be treated that
> way.
>
> 3. Have one lightweight D realized cross platform IDE. Qt us probably
> the best widget set to use for this. My model here is LiteIDE which is
> a Qt-based Go IDE realized in C++. It should of course be realized in
> Go, but there are no Qt bindings for Go, only QML ones.
>

If anything is to be done about improving the IDE tooling, it should be work on a tool like D Completion Daemon (DCD) - that is, an IDE-agnostic tool for code completion and other language analysis functionality (find-references, refactor, etc.)

The IDE space is just too fragmented - there are now even more popular IDEs that than say 5 years ago - like VS Code, Atom, etc.. Even SublimeText is a relatively recent player.  As such it's not feasible to be focusing a work on just a few IDEs. You have to make the core of IDE functionality available in an IDE-agnostic tool.

VSCode for example has even defined a language-agnostic protocol for such language servers: https://github.com/Microsoft/vscode-languageserver-protocol/ , and there is work in a few other IDEs to adopt that protocol as well, and write their own IDE client implementation (Eclipse for example, but it's all very early stages).


In any case, this is all of secondary importance, IMO. The GC issue is much more critical. If people think D has a worthwhile future for building apps in real world scenarios, then the tooling will get there eventually, it will catch up. But if people think other languages will work much better for their needs (like Rust or others), no amout of exceptional tooling will make a difference.


BTW, "finished" is not the right word to describe the state of DDT, if anything it's now in maintenance mode. (actually not that different from what it has been in the last 1 year or so)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

As someone learning D, I thought I would give my insight in how I came to D.

My biggest reason for choosing D is the GC. I have come from Java and don't quite believe that I'm ready to manage my own memory throughout an entire program, but the ability to disconnect from the GC is a great way to start. I'm not saying that D should be a stopgap language, it has far too much potential for that.

I think that D definitely has many positives but that there is still work that needs to go into it. But all languages need work, no language is perfect.

I don't have much insight onto how the long term development and goals have gone, but I see that D is moving in a good direction and hope it will be around for many years to come. I also wish that D would have a wider adoption.

As it goes for tools. I agree work needs to be done on them but that it is not as important as a well done, competent compiler set and great documentation. D has great docs, and a quite competent compiler group.

On Monday, 6 June 2016 at 06:29:27 UTC, Andrei Alexandrescu wrote:
> On 6/6/16 6:17 AM, Andre Pany wrote:
>> to be usable for companies which want to create economic software,
>> in my opinion D lacks std.decimal.
>
> Do C, C++, Java, Go, or Rust have a standard decimal type? -- Andrei

Hello Andrei, there's a nice arbitrary precision arithmetic library for Java: http://apfloat.org/apfloat_java - we used it some time ago because we had to mirror Oracle's number precision. It also provides all important arithmetic, trigonometric and other functions we need. There's C++ version too: http://apfloat.org/apfloat/2.41 - but I don't know if it has all the features Java version has, it was last updated at 2006.

I think it would be very very nice to have it ported to D...

Sorry for bothering you, I'm new to D language, I have bought a book and I'm learning now, but the project I think I will write in D needs to mirror Oracle's number or Postgresql's numeric precision too... Yes, there will be minimal need of that precision in reality and I can live with decimal[32|64|128] for now.

Best regards, Radek

On Wednesday, 7 April 2021 at 14:21:40 UTC, Radek wrote:
> On Monday, 6 June 2016 at 06:29:27 UTC, Andrei Alexandrescu wrote:
>> On 6/6/16 6:17 AM, Andre Pany wrote:
>>> to be usable for companies which want to create economic software,
>>> in my opinion D lacks std.decimal.
>>
>> Do C, C++, Java, Go, or Rust have a standard decimal type? -- Andrei
>
> Hello Andrei, there's a nice arbitrary precision arithmetic library for Java: http://apfloat.org/apfloat_java - we used it some time ago because we had to mirror Oracle's number precision. It also provides all important arithmetic, trigonometric and other functions we need. There's C++ version too: http://apfloat.org/apfloat/2.41 - but I don't know if it has all the features Java version has, it was last updated at 2006.
>
> I think it would be very very nice to have it ported to D...
>
> Sorry for bothering you, I'm new to D language, I have bought a book and I'm learning now, but the project I think I will write in D needs to mirror Oracle's number or Postgresql's numeric precision too... Yes, there will be minimal need of that precision in reality and I can live with decimal[32|64|128] for now.
>
> Best regards, Radek

What about CustomFloat (https://dlang.org/phobos/std_numeric.html#.CustomFloat) or
https://github.com/andersonpd/decimal that's an implementation of http://www.speleotrove.com/decimal/decarith.pdf or
http://rumbu13.github.io/decimal/doc/decimal.html or
https://github.com/Remotion/decimal