November 02, 2014
Andrei Alexandrescu:

> Is that a best-effort kind of approach? If so, that would be pretty bad...

I don't exactly know how that Rust macro works, sorry, I am still rather ignorant about Rust.

Bye,
bearophile
November 02, 2014
On Sunday, 2 November 2014 at 22:02:05 UTC, Andrei Alexandrescu wrote:
> On 11/2/14 2:11 AM, Paolo Invernizzi wrote:
>> On Sunday, 2 November 2014 at 01:28:15 UTC, H. S. Teoh via Digitalmars-d
>> wrote:
>>>
>>> 1) Compile-time verification of format arguments -- passing the wrong
>>> number of arguments or arguments of mismatching type will force
>>> compilation failure. Currently, it will compile successfully but fail at
>>> runtime.
>>
>> +1000! That would be awesome!
>>
>> It would be a _great_ boost in productivity during the debugging phase,
>> or when we are under pressure and can't do a great job in code coverage.
>
> Compile-time checking of format strings is nice to have, but I hardly see it as a major productivity boost. Maybe the better effect would be it serving as an example for other libraries to follow. -- Andrei

For sure it is a boost: the raising of such exception is not so uncommon, and I assure that here at work is one of the top 5 cursed things when it happens.

Top of the pop, for cursing, when it happens in production.

---
Paolo




November 03, 2014
On Sunday, 2 November 2014 at 22:11:51 UTC, bearophile wrote:
> Andrei Alexandrescu:
>
>> Is that a best-effort kind of approach? If so, that would be pretty bad...
>
> I don't exactly know how that Rust macro works, sorry, I am still rather ignorant about Rust.
>
> Bye,
> bearophile

There is a guide in case you aren't aware of it, http://doc.rust-lang.org/guide-macros.html

I think the plan is to have them comparable to Lisp macros in expressiveness.

--
Paulo
November 03, 2014
On 11/2/14 11:11 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> Is that a best-effort kind of approach? If so, that would be pretty
>> bad...
>
> I don't exactly know how that Rust macro works, sorry, I am still rather
> ignorant about Rust.

Then don't mention it in the first place. You either make points you can stand by on don't. Don't fumble around. -- Andrei


November 03, 2014
Andrei Alexandrescu:

> Then don't mention it in the first place. You either make points you can stand by on don't. Don't fumble around. -- Andrei

There's also a third option, offer the information I have, if it's valuable, even when it's not complete because others can get interested and find the full information themselves (note: this is how science works in laboratories).

Bye,
bearophile
November 03, 2014
On 11/3/14 12:12 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> Then don't mention it in the first place. You either make points you
>> can stand by on don't. Don't fumble around. -- Andrei
>
> There's also a third option, offer the information I have, if it's
> valuable, even when it's not complete because others can get interested
> and find the full information themselves (note: this is how science
> works in laboratories).

That's fine so long as it comes with clear disclosure. -- Andrei

November 03, 2014
On 02/11/2014 20:33, Walter Bright wrote:
> On 11/2/2014 12:12 PM, bearophile wrote:
>> I think the free mixing of signed and unsigned integral values is not
>> a good
>> idea in D.
>
> It's simply not workable to put a wall between them. Every proposal for
> it has entailed various unfortunate, ugly, and arbitrary consequences.

We need warnings like gcc has:

"-Wsign-compare
    Warn when a comparison between signed and unsigned values could produce an incorrect result when the signed value is converted to unsigned.

-Wconversion
    Warn for implicit conversions that may alter a value. This includes ... conversions between signed and unsigned, like unsigned ui = -1 ... Warnings about conversions between signed and unsigned integers can be disabled by using -Wno-sign-conversion.
"

It is really unfortunate that D is more bug-prone than gcc in this case. There was some promising work here:

https://github.com/D-Programming-Language/dmd/pull/1913
November 03, 2014
On Mon, Nov 3, 2014 at 3:42 PM, bearophile via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> There's also a third option, offer the information I have, if it's valuable, even when it's not complete because others can get interested and find the full information themselves

That's true. But when making points to high-level decision makers like Andrei, it is often more productive to do the research oneself and present the result and not just chime in with pointers because they don't have the time to follow those pointers. (pun intended)

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

November 03, 2014
On Saturday, 1 November 2014 at 20:14:15 UTC, Walter Bright wrote:
>
> Jonathan is reinventing D with a somewhat different syntax. Some points on the video:


May be you should have a couple of beers with him too, just like you did with Andrei a long time ago! :)
November 03, 2014
On 11/3/14 10:10 PM, John wrote:
> On Saturday, 1 November 2014 at 20:14:15 UTC, Walter Bright wrote:
>>
>> Jonathan is reinventing D with a somewhat different syntax. Some
>> points on the video:
>
>
> May be you should have a couple of beers with him too, just like you did
> with Andrei a long time ago! :)

I'm considering writing an open letter responding to all videos, give Jonathan a first crack at reviewing it, and then meeting for beers. -- Andrei