Re: SAL at Microsoft

2011-03-01 Thread Don
bearophile wrote: Adam Ruppe: Just accept the few kilobytes of unbearable bloat and use writef, It's not just template bloat, but also the printing bugs not caught at compile time. The point of the first post of this thread was to talk about SAL, that Microsoft seems to consider very import

Re: SAL at Microsoft

2011-02-28 Thread bearophile
Adam Ruppe: > Just accept the few kilobytes of unbearable bloat and use writef, It's not just template bloat, but also the printing bugs not caught at compile time. The point of the first post of this thread was to talk about SAL, that Microsoft seems to consider very important. I think this pa

Re: SAL at Microsoft

2011-02-28 Thread Adam Ruppe
bearophile wrote: > So there's no way out. Just accept the few kilobytes of unbearable bloat and use writef, or write the necessary code yourself so all the burden isn't on Walter.

Re: SAL at Microsoft

2011-02-28 Thread bearophile
> Good "pluggable type systems" are a general solution usable for many other > purposes too, I guess you don't like this, right? If I ask you a special-purpose solution for just printing functions, you answer me that it's a wired solution, etc. If I answer with a more general solution like plug

Re: SAL at Microsoft

2011-02-28 Thread spir
On 02/28/2011 09:50 PM, bearophile wrote: spir: Language design meets ecology... A feature that's good in Python may be bad in D, or not having a feature in Python may be bad, while missing it in D may be good. When you judge how much good a language feature is, you must take a look at how

Re: SAL at Microsoft

2011-02-28 Thread bearophile
spir: > Language design meets ecology... A feature that's good in Python may be bad in D, or not having a feature in Python may be bad, while missing it in D may be good. When you judge how much good a language feature is, you must take a look at how the feature interacts with all the other fe

Re: SAL at Microsoft

2011-02-28 Thread spir
On 02/28/2011 08:59 PM, bearophile wrote: I don't think you will find a magic solution to remove the problem of template bloat. In past I have shown you three very different ideas to reduce template bloat. Just hoping in a better future is not enough. Like with cancer probably there is no sing

Re: SAL at Microsoft

2011-02-28 Thread bearophile
Walter: > Similarly, template bloat is a language implementation issue that needs > eventually to be addressed. Having a kludgy language feature that only > addresses > printf is the wrong fix. I don't think you will find a magic solution to remove the problem of template bloat. In past I hav

Re: SAL at Microsoft

2011-02-28 Thread Walter Bright
bearophile wrote: Walter: Won't implement, see rationale http://d.puremagic.com/issues/show_bug.cgi?id=4458#c6 In the same place I have written good answers to your problems. There's no technical reason why writef should be slower than printf, adding language features to compensate is the

Re: SAL at Microsoft

2011-02-28 Thread bearophile
Walter: > Won't implement, see rationale > http://d.puremagic.com/issues/show_bug.cgi?id=4458#c6 In the same place I have written good answers to your problems. bearophile

Re: SAL at Microsoft

2011-02-28 Thread Walter Bright
bearophile wrote: But I don't understand how a __format_string annotation helps here. If you have code like this: string f = "%d"; writeln(f, 10); Adding that annotation (here translated to a D annotation) doesn't help the compiler much: @format_string string f = "%d"; writeln(f, 10); Ther

Re: SAL at Microsoft

2011-02-28 Thread Kagamin
bearophile Wrote: > In most cases you don't want to print a format string, so if you write: > > @format_string string f = "%d"; > writeln(f, 10); > > The compiler is probably able to show a warning, that says that you are using > a format string as first argument of a printing function that doe

Re: SAL at Microsoft

2011-02-28 Thread bearophile
In many cases the format string is known at compile-time, so I am even able to create a function like this, that performs library-defined compile-time tests on the format string: putfnl!"Data: %d %f"(10, 1.5); Bye, bearophile

Re: SAL at Microsoft

2011-02-28 Thread bearophile
> But I don't understand how a __format_string annotation helps here. > > If you have code like this: > > string f = "%d"; > writeln(f, 10); > > Adding that annotation (here translated to a D annotation) doesn't help the > compiler much: > > @format_string string f = "%d"; > writeln(f, 10); T

Re: SAL at Microsoft

2011-02-28 Thread bearophile
Kagamin: >> _deref/_deref_opt/_opt: In D I have suggested the @ suffix to denote nonnull >> pointers/references. >> >> __checkReturn: GCC has a similar annotation, I have suggested something >> similar for D too. > > don't contracts do it already? If you are referring to the _deref/_opt then th

Re: SAL at Microsoft

2011-02-28 Thread Kagamin
bearophile Wrote: > _deref/_deref_opt/_opt: In D I have suggested the @ suffix to denote nonnull > pointers/references. > > __checkReturn: GCC has a similar annotation, I have suggested something > similar for D too. don't contracts do it already? > __format_string/__callback: interesting, bu

SAL at Microsoft

2011-02-27 Thread bearophile
It's the first time I read an article that explains the working life at Microsoft: http://foredecker.wordpress.com/2011/02/27/working-at-microsoft-day-to-day-coding/ This is one interesting thing: >Windows does have some Windows wide common coding practices. For example, we >use SAL annotations