gmane.comp.lang.d.general

Re: new DIP41: dmd/rdmd command line overhaul.

Jacob Carlborg — 2013-05-21T17:14:52


D will never be good if we're so afraid of breaking changes.

Re: std.uni vs std.unicode and beyond?

Jacob Carlborg — 2013-05-21T17:14:03

They had the correct name to begin with. Why std.algorithm or 
std.process wasn't shortened but std.uni was I have no idea. 
std.algorithm is a lot newer than the others.

Re: std.uni vs std.unicode and beyond?

Jacob Carlborg — 2013-05-21T17:12:12

How about std.encoding.unicode to get a proper hierarchy into phobos.

Re: std.uni vs std.unicode and beyond?

Jacob Carlborg — 2013-05-21T17:10:42


How about consistency? We don't want to look like PHP here.

It's great that we have a review queue, DIP's and pull request. But we 
still have all the existing code that was there before which we need to 
deal with.

Re: std.uni vs std.unicode and beyond?

Regan Heath — 2013-05-21T17:08:46

On Tue, 21 May 2013 17:52:10 +0100, Steven Schveighoffer  
<schveiguy< at >yahoo.com> wrote:


dmd -d


Ick no.

R

Re: new DIP41: dmd/rdmd command line overhaul.

Jacob Carlborg — 2013-05-21T17:04:21


I think the git command line syntax is pretty good and consistent.

Re: std.uni vs std.unicode and beyond?

Brad Anderson — 2013-05-21T17:03:09

I vote to rename it. It's hard to find for people new to phobos 
under the name "uni" (anecdotally, it took me awhile to find it 
when I was starting out and occasionally someone hops in IRC and 
asks about unicode and you typically have to point out to them 
that the unicode module is std.uni)  I've never seen unicode 
called "uni" outside of std.uni.

Re: External lib unittests: they're killin me!

Jacob Carlborg — 2013-05-21T17:02:19

That exact syntax will probably cause some problems with the shell.

Re: std.uni vs std.unicode and beyond?

nazriel — 2013-05-21T17:01:57

On Tuesday, 21 May 2013 at 16:52:06 UTC, Steven Schveighoffer 
wrote:

They do. Unless you add compiler switch they will compile and 
only spit out an warning.

Re: new DIP41: dmd/rdmd command line overhaul.

Walter Bright — 2013-05-21T17:01:12

I'm conflicted about it!

Re: std.uni vs std.unicode and beyond?

Steven Schveighoffer — 2013-05-21T16:52:10

On Tue, 21 May 2013 12:43:01 -0400, Regan Heath <regan< at >netmail.co.nz>  
wrote:



Deprecated functions don't compile.  Any code that uses it would have to  
be modified.

Only non-breaking solution would be to keep both.  In the past, it has  
been suggested to have std.uni simply publicly import std.unicode (or  
analogous solution to some other module renaming).  You would always  
retain std.uni in this solution.

-Steve

Re: std.uni vs std.unicode and beyond?

Regan Heath — 2013-05-21T16:43:01

On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer  
<schveiguy< at >yahoo.com> wrote:


Wouldn't the old std.uni remain but deprecated?

R

Re: new DIP41: dmd/rdmd command line overhaul.

Timothee Cour — 2013-05-21T16:37:42

On Tue, May 21, 2013 at 9:05 AM, Walter Bright
<newshound2< at >digitalmars.com>wrote:

In that post you seemed to agree:

http://forum.dlang.org/post/kk4ejt$1pnq$1< at >digitalmars.com

  >> I agree. The way to do it is to support both the old and the new ways
for now. Anyone want to do a pull req? Also, this should be put in bugzilla
as an enhancement request.

Re: std.uni vs std.unicode and beyond?

captaindet — 2013-05-21T16:34:25

+1

Re: std.uni vs std.unicode and beyond?

Steven Schveighoffer — 2013-05-21T16:25:23


It has nothing to do with the name.  I think unicode is better.  But  
(allegedly) we have existing projects that use std.uni, which would break  
if we renamed.  Even temporary relief such as an alias, deprecation,  
public import, etc would not be completely sufficient.


I don't disagree, but is it so bad that it's worth changing the name?   
That's all I'm saying, the bar has to be very high in order to require a  
name change.

In general, changing the name of something without any added benefit  
(aside from the benefit of clarity) needs a very strong case to make that  
change.  You are breaking code for no benefit to someone who doesn't care  
about the name.  As the standard library we have to be super sensitive to  
these cases.

-Steve

Re: External lib unittests: they're killin me!

Steven Schveighoffer — 2013-05-21T16:23:01

On Mon, 20 May 2013 21:52:51 -0400, Nick Sabalausky  
<SeeWebsiteToContactMe< at >semitwist.com> wrote:


I think we can handle this without compiler help.

The runtime is responsible for running unit tests.

It actually provides a hook to allow you to override the unit tests.  See  
here: http://dlang.org/phobos/core_runtime.html#.Runtime.moduleUnitTester  
(set in a shared static ctor).  All you have to do is just run the  
module's unit tests you desire.

I would argue the "stock" unit test runner could be configured by an  
environment variable to be able to run/exclude whatever you want.  This is  
eminently fixable in the library with a small pull request.

-Steve

Re: support UFCS with fully qualified function names (was in"digitalmars.D.learn")

nazriel — 2013-05-21T16:20:52

In overall it is rather rare case but if it happens I just use 
renamed or selective imports.

I am neutral on this just giving one of alternative solutions for 
this.

Re: std.uni vs std.unicode and beyond?

nazriel — 2013-05-21T16:11:33

Also we have std.algorithm, std.process etc and nobody complains 
that its name is too long.

Re: support UFCS with fully qualified function names (was in"digitalmars.D.learn")

Steven Schveighoffer — 2013-05-21T16:10:29

On Tue, 21 May 2013 03:09:15 -0400, bearophile <bearophileHUGS< at >lycos.com>  
wrote:


Is it just me, or is this not trivially solved with import aliases?

-Steve

Re: std.uni vs std.unicode and beyond?

nazriel — 2013-05-21T16:09:48

I would say that new module should be called std.unicode. It is 
way more clear what it does without looking up in docs. For code 
breakage, maybe public import in std.uni + pragma-msg about 
deprecation could lower it a bit?

Restructuring Phobos is really good idea but I would say we wait 
for DIP15 (or any variant) so we can make transition less 
painful. For example std.datetime split could be unnoticeable.

Re: new DIP41: dmd/rdmd command line overhaul.

Walter Bright — 2013-05-21T16:05:56

I generally agree with Andrei here. People hate it when their makefiles break. 
There needs to be an awfully good reason to do it, not just clean up.

Also,

     dmd -man

suffices for "long help". There is no reason to have 3 different help texts.