On 2014-09-25 19:26, Atila Neves wrote:

> I don't want an empty main function. I want the main function and the
> file it's in to be generated by the build system.

What do you want the main function to contain?

-- 
/Jacob Carlborg

On Thursday, 25 September 2014 at 15:58:11 UTC, eles wrote:
> On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg wrote:
>> On 25/09/14 09:38, Atila Neves wrote:
>>

> Andrei spoke about an idiom that they constantly use at Facebok, because there aparrently nobody runs *main and unittests*. So they keep a special empty main for the -unittest version.

This idiom here:

http://forum.dlang.org/post/ljr5n7$1leb$1@digitalmars.com

"Last but not least, virtually nobody I know runs unittests and then
main. This is quickly becoming an idiom:

version(unittest) void main() {}
else void main()
{
   ...
}

I think it's time to change that. We could do it the
non-backward-compatible way by redefining -unittest to instruct the
compiler to not run main. Or we could define another flag such as
-unittest-only and then deprecate the existing one.
"

On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:

> lack of attention paid to tightening up what we've already got and deprecating old stuff that no one wants any more.  And inconsistency in how things work in the language.

The feeling that I have is that if D2 does not get a serious cleanup at this stage, then D3 must follow quickly (and such move will be unstoppable), otherwise people will fall back to D1 or C++next.

On 9/25/2014 12:58 PM, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Sep 25, 2014 at 12:40:28PM -0700, Walter Bright via Digitalmars-d wrote:
>> On 9/25/2014 4:08 AM, Don wrote:
> [...]
>>> Ask yourself, if D had no users other than you, so that you break
>>> *anything*, what would you remove? Make a wishlist, and then find out
>>> what's possible.  Remember, when you did that before, we successfully
>>> got rid of 'bit', and there was practically no complaint.
>>
>> Top of my list would be the auto-decoding behavior of
>> std.array.front() on character arrays. Every time I'm faced with that
>> I want to throw a chair through the window.
>
> LOL... now I'm genuinely curious what's Andrei's comment on this. :-P
> Last I heard, Andrei was against removing autodecoding.

I have yet to completely convince Andrei that autodecoding is a bad idea :-(

On Thursday, 25 September 2014 at 21:03:24 UTC, eles wrote:
> On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:
>

BTW, am I the only one whose eyes/ears are suffering when reading this:

std.algrithm

"he stripLeft function will strip the front of the range, the stripRight function will strip the back of the range, while the strip function will strip both the front and back of the range. "

Why not, for God's sake, stripFront and stripBack?

In std.string too. What about the R2L languages?

On Thursday, 25 September 2014 at 21:10:51 UTC, eles wrote:
> On Thursday, 25 September 2014 at 21:03:24 UTC, eles wrote:
>> On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:
>>
>
> BTW, am I the only one whose eyes/ears are suffering when reading this:
>
> std.algrithm
>
> "he stripLeft function will strip the front of the range, the stripRight function will strip the back of the range, while the strip function will strip both the front and back of the range. "
>
> Why not, for God's sake, stripFront and stripBack?
>
> In std.string too. What about the R2L languages?

OTOH, there is bringToFront()

Really...

On Thursday, 25 September 2014 at 21:03:53 UTC, Walter Bright wrote:
> On 9/25/2014 12:58 PM, H. S. Teoh via Digitalmars-d wrote:
>> On Thu, Sep 25, 2014 at 12:40:28PM -0700, Walter Bright via Digitalmars-d wrote:
>>> On 9/25/2014 4:08 AM, Don wrote:
>> [...]
>>>> Ask yourself, if D had no users other than you, so that you break
>>>> *anything*, what would you remove? Make a wishlist, and then find out
>>>> what's possible.  Remember, when you did that before, we successfully
>>>> got rid of 'bit', and there was practically no complaint.
>>>
>>> Top of my list would be the auto-decoding behavior of
>>> std.array.front() on character arrays. Every time I'm faced with that
>>> I want to throw a chair through the window.
>>
>> LOL... now I'm genuinely curious what's Andrei's comment on this. :-P
>> Last I heard, Andrei was against removing autodecoding.
>
> I have yet to completely convince Andrei that autodecoding is a bad idea :-(

I think it should just refuse to work on char[], wchar[] and dchar[]. Instead, byCodeUnit, byCodePoint (which already exist) would be required. This way, users would need to make a conscious decision, and there would be no surprises and no negative performance impact.

eles:

> "he stripLeft function will strip the front of the range, the stripRight function will strip the back of the range, while the strip function will strip both the front and back of the range. "
>
> Why not, for God's sake, stripFront and stripBack?

Perhaps those names come from extending the names of "lstrip" and "rsplit" of Python string functions.

Bye,
bearophile

On Thursday, 25 September 2014 at 21:22:38 UTC, bearophile wrote:
> eles:
>
>> "he stripLeft function will strip the front of the range, the stripRight function will strip the back of the range, while the strip function will strip both the front and back of the range. "
>>
>> Why not, for God's sake, stripFront and stripBack?
>
> Perhaps those names come from extending the names of "lstrip" and "rsplit" of Python string functions.
>
> Bye,
> bearophile

I find it too inconsitent. I doubt even Python programmers migrating to D love that...

And, just: std.uni->std.unicode

And I cannot believe that the language-defined complex types are still there (since the D1 days...). Either in the library, either in the language, but, please, pick *one* kind.

On Thu, Sep 25, 2014 at 09:19:29PM +0000, via Digitalmars-d wrote:
> On Thursday, 25 September 2014 at 21:03:53 UTC, Walter Bright wrote:
[...]
> >I have yet to completely convince Andrei that autodecoding is a bad idea :-(

It certainly represents a runtime overhead, which may be non-negligible depending on your particular use case, and despite oft stated benefits of being Unicode-aware by default (well, not 100%), I think the cost of maintaining special-casing for narrow strings is starting to show up in the uglification of Phobos range-based code. Ranges were supposed to help with writing cleaner, more generic code, but I've been observing a trend of special-casing in order to reduce the autodecoding overhead in string handling, which somewhat reduces the cleanness of otherwise fully-generic code.  This complexity has led to string-related bugs, and definitely has a cost on the readability (and, consequently, maintainability) of Phobos code. Special cases hurt generic code. It's not just about performance.


> I think it should just refuse to work on char[], wchar[] and dchar[]. Instead, byCodeUnit, byCodePoint (which already exist) would be required.  This way, users would need to make a conscious decision, and there would be no surprises and no negative performance impact.

Not a bad idea. If we do it right, we could (mostly) avoid user outrage. E.g., start with a "soft deprecation" (a compile-time message, but not an actual warning, to the effect that byCodeUnit / byCodePoint should be used with strings from now on), then a warning, then an actual deprecation, then remove autodecoding code from Phobos algorithms (leaving only byCodePoint for those who still want autodecoding).


T

-- 
Two wrongs don't make a right; but three rights do make a left...