On Wednesday, 12 June 2013 at 12:50:39 UTC, Andrei Alexandrescu wrote:
> Reddit: http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/
>
> Hackernews: https://news.ycombinator.com/item?id=5867764
>
> Twitter: https://twitter.com/D_Programming/status/344798127775182849
>
> Facebook: https://www.facebook.com/dlang.org/posts/655927124420972
>
> Youtube: http://youtube.com/watch?v=ph_uU7_QGY0
>
> Please drive discussions on the social channels, they help D a lot.
>
>
> Andrei

The restrictions on contracts were very interesting. Obviously the static analysis could be more sophisticated than what you currently have, but
 I don't think contracts can be much use to a static analyzer if they can contain arbitrary code.

I would be interested to see how much freedom is actually required, in order to make contracts adequately expressive. Perhaps it was a language mistake to allow arbitrary code inside contracts, it might have been better to start with something very restricted and gradually relax the rules.

Jacob Carlborg:

> Walter likes the simplicity of the unit test system.

Maybe Walter is slowly realizing that the built-in uinittest system doesn't cut it. I am saying this since years.

On the other hand, unittest systems come and go, while D language must be designed to last 10 or 20 years. So hard coding too much of a unittest design inside the language risks introducing something that few years from now will become obsolete (hopefully something like QuickCheck will become more commonly used in D).

So I suggested to offer the tools, but not a complete built-in solution.

Bye,
bearophile

Don:

> I don't think contracts can be much use to a static analyzer if they can contain arbitrary code.

The other contract systems I know of (Eiffel, Ada, C#, Sing#), plus few other systems that use the type system for similar reasons (Liquid Haskell, etc), use a very restricted expression language to state contracts. D is the only that uses free form D code.

I presented this problem to Walter lot of time ago in a post. He answered me that analysing a loop is not harder than analysing the all/any/exists used in those systems. I was never convinced by that.

I still think there's one D design problem here.

Bye,
bearophile

On 2013-06-14 10:58, bearophile wrote:

> So I suggested to offer the tools, but not a complete built-in solution.

I agree. You can get quite far with what we have now and library support. Perhaps we could have a couple of different implementations in druntime that we can choose from.

-- 
/Jacob Carlborg

On Fri, 14 Jun 2013 05:12:09 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2013-06-14 10:58, bearophile wrote:
>
>> So I suggested to offer the tools, but not a complete built-in solution.
>
> I agree. You can get quite far with what we have now and library support. Perhaps we could have a couple of different implementations in druntime that we can choose from.

With @UDAs, we have a lot of unrealized power for unit tests.

I have asked for ModuleInfo to contain an rtInfo member [1], like TypeInfo does.  With that, and possibly splitting the unit tests into individual functions (if not done already, I don't know), you have all you need to completely re-design the unit testing framework.  It can even be runtime selectable.

-Steve

[1] http://d.puremagic.com/issues/show_bug.cgi?id=10023

Slowly catching up with published videos :)

This has kind of convinced me that once D gets wider usage, tools similar to AnalyzeD may become de-facto standard part of any production toolchain, with a configurable rule set. D is complex and multi-paradigm language (which rocks) and any single project is likely to use only specific style subset (which is kind of hard to enforce). Once front-end parses becomes less coupled with rest of the compiler it should become more and more popular approach.

On 2013-06-12 14:50, Andrei Alexandrescu wrote:
> Reddit:
> http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/
>
>
> Hackernews: https://news.ycombinator.com/item?id=5867764
>
> Twitter: https://twitter.com/D_Programming/status/344798127775182849
>
> Facebook: https://www.facebook.com/dlang.org/posts/655927124420972
>
> Youtube: http://youtube.com/watch?v=ph_uU7_QGY0

As I understand it, the static analyzer doesn't handle D completely. How does it behave/what happens if it encounters something it cannot handle?

-- 
/Jacob Carlborg

On 2013-06-14 17:13, Steven Schveighoffer wrote:

> With @UDAs, we have a lot of unrealized power for unit tests.
>
> I have asked for ModuleInfo to contain an rtInfo member [1], like
> TypeInfo does.  With that, and possibly splitting the unit tests into
> individual functions (if not done already, I don't know), you have all
> you need to completely re-design the unit testing framework.  It can
> even be runtime selectable.

It would also be nice to not have to change the druntime to use RTInfo. Is that part of what you're suggesting?

-- 
/Jacob Carlborg

On 06/14/2013 11:03 AM, bearophile wrote:
> Don:
>
>> I don't think contracts can be much use to a static analyzer if they
>> can contain arbitrary code.
>
> The other contract systems I know of (Eiffel, Ada, C#, Sing#), plus few
> other systems that use the type system for similar reasons (Liquid
> Haskell, etc), use a very restricted expression language to state
> contracts. D is the only that uses free form D code.
>

Eiffel can call arbitrary methods in contracts.

> I presented this problem to Walter lot of time ago in a post. He
> answered me that analysing a loop is not harder than analysing the
> all/any/exists used in those systems. I was never convinced by that.
>
> I still think there's one D design problem here.
>...

I disagree. The only problem is the verboseness of the contract system.

On 06/15/2013 05:14 PM, Jacob Carlborg wrote:
> On 2013-06-12 14:50, Andrei Alexandrescu wrote:
>> Reddit:
>> http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/
>>
>>
>>
>> Hackernews: https://news.ycombinator.com/item?id=5867764
>>
>> Twitter: https://twitter.com/D_Programming/status/344798127775182849
>>
>> Facebook: https://www.facebook.com/dlang.org/posts/655927124420972
>>
>> Youtube: http://youtube.com/watch?v=ph_uU7_QGY0
>
> As I understand it, the static analyzer doesn't handle D completely. How
> does it behave/what happens if it encounters something it cannot handle?
>

It bails out.