On Sunday, 2 November 2014 at 18:04:18 UTC, Ary Borenszweig wrote:

> About the bytecode he generates: as someone said in the reddit discussion, having to maintain two separate language implementations (compiled and interpreted) can lead to small and subtle bugs. And, running code via an intepreter is slower than compiled code, even if the interpreter is really good. So I don't think the bytecode stuff is a really good idea.

Well, D maintains several implementations (interpreter for CTFE and the backends), and the interpreter doesn't even use byte code so it's probably even slower. Is it really a problem? Sometimes, probably, but not too often.

Am Mon, 03 Nov 2014 16:29:17 -0800
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 11/3/2014 10:03 AM, Nick Treleaven wrote:
> > On 02/11/2014 20:33, Walter Bright wrote:
> >> 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.
> > "
> 
> I find these to suffer from the same problems as all the proposals to "fix" the issue - they motivate the user to "fix" them with unfortunate, ugly, and arbitrary consequences.
> 
> We need to be very careful with the idea of "just add a warning". Warnings are a sure sign of wishy-washy language design where the designers cannot make up their mind, so they dump it on the user. One person's warning become another person's must fix, and the language becomes balkanized, which is not good for portability, comprehensibility, and best practices.

Although I might agree that warnings can indicate 'wishy-washy language
design' you can not simply assume the reverse/negation. There's
obviously a problem and just 'not adding warnings' doesn't magically
solve this 'wishy-washy language design' issue.
And as long as there is no other solution warnings are better than
simply ignoring the problem.

But I think it's likely this check will be implemented in Dscanner (https://github.com/Hackerpilot/Dscanner/issues/204) and in the end it doesn't really matter where it's implemented.

On 2014-11-04 09:48, Meta wrote:

> Isn't SDC already able to do JIT compilation for CTFE? I swear I've seen
> Deadalnix mention it before...

Forgot about that.

-- 
/Jacob Carlborg

On 2014-11-04 10:08, deadalnix wrote:

> Yes, SDC use LLVM's JIT capability to do CTFE.

Can't it access parts of the system that DMD's CTFE cannot?

-- 
/Jacob Carlborg

On Tuesday, 4 November 2014 at 17:18:25 UTC, Jacob Carlborg wrote:
> On 2014-11-04 10:08, deadalnix wrote:
>
>> Yes, SDC use LLVM's JIT capability to do CTFE.
>
> Can't it access parts of the system that DMD's CTFE cannot?

Yes, I have yet to implement a check for ctfeability.

On 2014-11-04 23:18, deadalnix wrote:

> Yes, I have yet to implement a check for ctfeability.

Cool, perhaps you should not add it :)

-- 
/Jacob Carlborg

On Wednesday, 5 November 2014 at 07:33:37 UTC, Jacob Carlborg
wrote:
> On 2014-11-04 23:18, deadalnix wrote:
>
>> Yes, I have yet to implement a check for ctfeability.
>
> Cool, perhaps you should not add it :)

My plan is to add the check for CTFE, but at the point in the
semantic analysis, not in the JIT part, so it is still possible
to run it without the check if wanted from 3rd party code (REPL
anyone ?).

On 04/11/2014 14:18, Johannes Pfau wrote:
> And as long as there is no other solution warnings are better than
> simply ignoring the problem.

+1

> But I think it's likely this check will be implemented in
> Dscanner (https://github.com/Hackerpilot/Dscanner/issues/204) and
> in the end it doesn't really matter where it's implemented.

While that's better than nothing, it does matter where it's implemented. It means you only detect problems when remembering to run Dscanner. If you wire it into your build system, you've added a new dependency* to keep track of. You have to hope Dscanner continues to be maintained and kept in sync with your D compiler (not just that it builds, but it understands the latest D syntax and semantic changes).

* For this reason, in practice, most small D projects won't use Dscanner regularly.

On 04/11/2014 02:00, Walter Bright wrote:
> You are glossing over and dismissing the problems with explicit casts,
> and the problems with overloading, etc.

Can't solving any overloading problem be deferred? An incomplete solution is better than nothing.

As for explicit casts, they are easily avoided using std.conv:

uint u = unsigned(-1);
int i = signed(uint.max);

The compiler can recommend these instead of explicit casts.

Also, please note the pull request I linked tries hard using VRP to avoid nagging the user with warnings/errors that it can detect are unnecessary.

Given that Andrei pre-approved the design last April year*, it seems surprising there's not yet been a solution.

* https://issues.dlang.org/show_bug.cgi?id=259#c35

On 11/6/2014 9:16 AM, Nick Treleaven wrote:
> On 04/11/2014 02:00, Walter Bright wrote:
>> You are glossing over and dismissing the problems with explicit casts,
>> and the problems with overloading, etc.
>
> Can't solving any overloading problem be deferred? An incomplete solution is
> better than nothing.

If the overloading issue can't reasonably be dealt with, then we have more problems.