Re: The One-Letter Nested Function - a sample article for some kind of

[F i L]

On Monday, 13 February 2012 at 14:14:38 UTC, bearophile wrote:

Zach the Mystic:


void setRandomColorPair( ref ColorPair cp )
{
import std.random;
ubyte u(int a, int b) { return cast(ubyte) uniform(a,b); }


Where possible it's good to add "static" to nested functions:

static ubyte u(in int a, in int b) pure nothrow { return 
cast(ubyte) uniform(a,b); }


I sorta figured D would implicitly attribute "static" to nested 
functions if the function didn't use any variables outside it's 
scope. Is that not so? Why are you saying it's a good idea to use 
"static" exactly?

Re: Arbitrary abbreviations in phobos considered ridiculous

[Jonathan M Davis]

On Saturday, March 10, 2012 02:21:56 Nick Sabalausky wrote:
> "Jonathan M Davis"  wrote in message
> > I'd say that there's a higher chance of the aliases being added than of
> > dur
> > being changed to duration. Changing dur will _definitely_ break code and
> > make
> > using it worse for exactly the same reason that it's dur in the first
> > place -
> > it's too long when combined with the required units string. The aliases
> > might
> > break code, but it's probably only in cases where someone already has free
> > functions with those names, and it's more likely that they'll have
> > variables
> > with those names, which are less likely to conflict.
> > 
> > So, while I don't really like the idea of adding the aliases, they _might_
> > be
> > added, because they probably won't break anything, and they enable UFCS.
> > But
> > there's not a good enough reason to change dur to duration at this point.
> 
> They eliminate the *entire* reason for it ever even being "dur" in the first
> place.

No, they don't. You have to keep dur if you want to enable generic code. Yes, 
if the aliases get added, people can choose to use them instead, but that 
doesn't negate the value of dur. It only makes it so that it's not the only 
option.

> Of course, if this incarnation of std.datetime were a few years old, then
> I'd likely agree with you, but it *is* still relatively new.

As far as I'm concerned, changing dur to duration breaks code to no benefit. 
It's a pointless renaming. And regardless of how new core.time and 
std.datetime are, pretty much any D code doing date/time stuff right now will 
be using it unless it hasn't been updated any time recently, because std.date 
has been deprecated, and it's going to be removed in the next release.

So, as far as I'm concerned, there is _no_ way that dur is going to be change 
to duration. And that's exactly the sort of thing that Walter is complaining 
about in his thread of making breaking changes.

We might merge in the aliases, since they'll improve the situation with UFCS, 
but there's no way that dur is getting changed. It's a trivial change for 
trivial benefit, and honestly, I think that it's _worse_ for the very reasons 
that I chose dur in the first place. dur!"hours" is pretty much just as clear 
as duration!"hours", and it's shorter.

- Jonathan M Davis

Re: Breaking backwards compatiblity

[Nick Sabalausky]

"H. S. Teoh"  wrote in message 
news:mailman.398.1331362435.4860.digitalmar...@puremagic.com...
> On Sat, Mar 10, 2012 at 01:44:59AM -0500, Nick Sabalausky wrote:
>> "Adam D. Ruppe"  wrote in message
>> news:wirsowklisbhbkbuj...@forum.dlang.org...
> [...]
>> > We might have a stable language, but if the library doesn't do the
>> > same, we'll never be Windows.
>
> Really? D is a stable language as of this moment? Interesting.
>
>
>> If we start freezing things now, we're going to be Windows 9x.
>
> You mean Windows 3.1.
>

I was pretty happy with 3.1. It's terrible in retrospect, but viewed in the 
context of the early 90's, I don't think it was bad at all. Maybe not as 
stable as the Unix of the time (I wouldn't know), but it was usable by mere 
mortals and was still a lot more robust than WinMe.

But then around the time of 98SE and Me, the 9x line just wasn't up to even 
the current expectations of the time. (And maybe my memory's foggy, but I 
seem to remember having more troubles with 98 than I did with 3.1. And Me 
was definitely much worse.)

Re: Arbitrary abbreviations in phobos considered ridiculous

[Nick Sabalausky]

"Andrei Alexandrescu"  wrote in message 
news:jjengv$agm$1...@digitalmars.com...
>
> Insert obligatory link: http://drdobbs.com/184401197
>
> Very insightful article.
>

Jesus christ what the FUCK is wrong with Dr Dobbs? The article shows up 
*just fine* - *at first*, and then once all the excess junk around the edges 
finishes loading, the stupid fucking thing redirects me (WITH NO BACK 
BUTTON!) to this useless shit: http://m.drdobbs.com/

What the fuck is wrong with web developers? You'd think at a 
***PROGRAMMING*** MAGAZINE they could fucking get basic shit straight 
without scrwing up things that a NOVICE wouldn't even KNOW how to fuck up! 
Goddamn.

It sounds like a great article, judging by the first paragraph, but I have 
to read it a couple sentences at a time. How the hell do "professions" botch 
things up *that* badly?

Re: Arbitrary abbreviations in phobos considered ridiculous

[Nick Sabalausky]

"Jonathan M Davis"  wrote in message 
news:mailman.366.1331335812.4860.digitalmar...@puremagic.com...
> On Friday, March 09, 2012 16:16:56 Brad Anderson wrote:
>> On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis 
>> wrote:
>> > On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote:
>> > > I'll say I *don't* agree with the rejection of aliases on 
>> > > principle --
>> > > aliases can be extremely useful/helpful, and they cost literally 
>> > > nothing
>> > > (the "cognitive cost" on the docs is a BS argument IMO). I just don't
>> > > agree with consuming so many common symbols for the sake of sugar.
>> >
>> > aliases need to have a really good argument for existing. If UFCS is 
>> > fully
>> > implemented, then I think that there is _some_ argument for having 
>> > stuff
>> > like
>> > hours and minutes, because then you can do stuff like 5.seconds() 
>> > (though
>> > honestly, I really don't like the idea). The alias enables different
>> > usages
>> > rather than simply being another name for the same thing.
>> >
>> > Now, in this particular case, it's that much worse for exactly the 
>> > reason
>> > that
>> > you're against it: it uses common names for free functions. It's not as
>> > big a
>> > problem as it would be in C or C++, but it's still a problem. There's 
>> > also
>> > some risk that it will break code.
>>
>> Oh, and I'd just like to add some of my experience to this. These names 
>> are
>> used by Boost's datetime library and they've never been a problem for me
>> and at work we make extensive use of Boost datetime. There is risk but I
>> think in this specific case they are fairly small (especially in D, over
>> C++). We switched to Boost datetime after we had hundreds of thousands of
>> lines of code written using a different system and I didn't encounter any
>> problems with the duration shortcut functions clashing.
>>
>> Anyway, it sounds like Walter is probably opposed from what he was saying
>> in the other thread so this conversation is probably moot.
>
> I'd say that there's a higher chance of the aliases being added than of 
> dur
> being changed to duration. Changing dur will _definitely_ break code and 
> make
> using it worse for exactly the same reason that it's dur in the first 
> place -
> it's too long when combined with the required units string. The aliases 
> might
> break code, but it's probably only in cases where someone already has free
> functions with those names, and it's more likely that they'll have 
> variables
> with those names, which are less likely to conflict.
>
> So, while I don't really like the idea of adding the aliases, they _might_ 
> be
> added, because they probably won't break anything, and they enable UFCS. 
> But
> there's not a good enough reason to change dur to duration at this point.
>

They eliminate the *entire* reason for it ever even being "dur" in the first 
place.

Of course, if this incarnation of std.datetime were a few years old, then 
I'd likely agree with you, but it *is* still relatively new.

Re: Arbitrary abbreviations in phobos considered ridiculous

[Nick Sabalausky]

"Jonathan M Davis"  wrote in message 
news:mailman.375.1331338580.4860.digitalmar...@puremagic.com...
>
> Which is one of the reasons that I really don't like the idea. Sometimes 
> it's
> nice with strings, but it creates inconsistencies, and stuff like 5.max(7) 
> just
> seems insane. UFCS will give people more freedom and may help templates in
> some cases, but I think that it's a major step back for readibility in
> general.
>

This is why C# requires that you declare a function to be UFCS in order to 
actualy use it with UFCS syntax (although they don't call it UFCS). I used 
to be pretty strongly in favor of that, but I've since gotten used to D's 
lax-ness about it.

Re: Breaking backwards compatiblity

[Nick Sabalausky]

"Walter Bright"  wrote in message 
news:jjeqak$f3i$1...@digitalmars.com...
> On 3/9/2012 9:14 PM, Andrei Alexandrescu wrote:
>> On 3/9/12 8:35 PM, Walter Bright wrote:
>>> On 3/9/2012 3:14 PM, bearophile wrote:
 D will naturally progressively slow down the rhythm of its new breaking
 changes, but even very old languages introduce some breaking changes 
 (see
 some of the changes in C++11),
>>>
>>> What breaking changes are there in C++11, other than dumping export?
>>
>> Deprecating exception specifications :o).
>
> I don't think that broke any existing code, because there wasn't any :-)
>
> Consider that I and some others agitated for dumping trigraphs. A couple 
> of people voiciferously claimed that their entire code base depended on 
> it, so it stayed in.
>
> Never mind that that codebase could be easily accommodated by writing a 
> literally trivial filter.
>
> But now, to support raw string literals, C++11 has mucked up trigraphs. 
> It's no longer possible to deprecate them without writing a filter that is 
> pretty much a full blown C++ compiler itself.

So making improvements that involve trivially-handled breaking changes is 
good for C++ but bad for D?

Re: Breaking backwards compatiblity

[H. S. Teoh]

On Sat, Mar 10, 2012 at 01:44:59AM -0500, Nick Sabalausky wrote:
> "Adam D. Ruppe"  wrote in message 
> news:wirsowklisbhbkbuj...@forum.dlang.org...
[...]
> > We might have a stable language, but if the library doesn't do the
> > same, we'll never be Windows.

Really? D is a stable language as of this moment? Interesting.


> If we start freezing things now, we're going to be Windows 9x.

You mean Windows 3.1.


T

-- 
Without outlines, life would be pointless.

Re: Breaking backwards compatiblity

[Nick Sabalausky]

"Adam D. Ruppe"  wrote in message 
news:wirsowklisbhbkbuj...@forum.dlang.org...
> On Saturday, 10 March 2012 at 04:40:11 UTC, Adam D. Ruppe wrote:
>> Yeah, the kernel is decent about it, but the rest of the
>> system sure as hell isn't.
>
> Let me tie this into D. A couple weeks ago, I revived one of
> my work D projects - about 30,000 lines of code - that was
> dormant for about a year.
>
> The language worked fine. The library was a bit more of
> a pain.
>
> std.date's deprecation still makes me mad.
>
> And the move of std.string.replace over to std.array meant
> not one of the modules compiled without a change.
>
> (Really easy change: "import std.string : replace;" why
> that works and  "import std.string;" doesn't I'm not sure.
> I'm probably relying on a bug here!)
>
>
>
> But still, the D language manages to move forward without
> much breakage. dmd pretty much gets better each release.
>
>
> Phobos has some breakage though. Not really bad; updating
> this code went quickly. I think I spent half an hour on it.
> But, there was some minor changes needed.
>
>
>
> We might have a stable language, but if the library doesn't
> do the same, we'll never be Windows.

If we start freezing things now, we're going to be Windows 9x.

Re: Breaking backwards compatiblity

[Nick Sabalausky]

"Walter Bright"  wrote in message 
news:jjelk7$7fm$1...@digitalmars.com...
> On 3/9/2012 3:09 PM, Nick Sabalausky wrote:
>> Keep in mind, too, that Linux has decades of legacy and millions of 
>> users.
>> That's a *very* different situation from Phobos. Apples and oranges.
>
> Linux has had a habit of not breaking existing code from decades ago. I 
> think that is one reason why it has millions of users.
>
> Remember, every time you break existing code you reset your user base back 
> to zero.
>
> I'm *still* regularly annoyed by the writefln => writeln change in D1 to 
> D2, and I agreed to that change. G.

Are you kidding me? I'm *thrilled* with how much of an improvement writeln 
is *every time I use it*.

Seriously how the hell did writeln ever hurst *anyone*? We're bitching about 
trivialities here.

Re: Multiple return values...

[Andrei Alexandrescu]

On 3/9/12 9:35 PM, Robert Jacques wrote:

On Fri, 09 Mar 2012 22:16:44 -0600, Andrei Alexandrescu
 wrote:

On 3/9/12 3:59 PM, Timon Gehr wrote:

Notably, there is no convenient unpacking syntax. Walter does not merge
the patches of Kenji Hara that would fix this because presumably he
fears it could get in the way of a more general solution.


This is because we need to think about that stuff to maximize its
generality.


Was simply applying the unpacking rules to all types (i.e. structs,
classes, etc) ever considered?


How would that work?

Andrei

Re: covariance of 'out' parameters is crucial for polymorphism and function subtyping

[Walter Bright]

On 3/9/2012 4:59 PM, Boscop wrote:

It is crucial for function subtyping, because functions are only contravariant
in their 'in' parameters, but covariant in their 'out' parameters and return 
type.
Function subtyping matters not only in classes with methods that have 'out'
parameters but also when assigning functions to function pointers or passing
functions as argument to other functions.


I agree that this should be implemented.

Re: Breaking backwards compatiblity

[Jonathan M Davis]

On Friday, March 09, 2012 21:54:28 Walter Bright wrote:
> > Deprecating exception specifications :o).
> 
> I don't think that broke any existing code, because there wasn't any :-)

Sadly, there's code that will break because of that where _I_ work. For a 
while, they were recommended/required, because some of the people dictating 
coding standards didn't understand them properly. Fortunately, much of the 
newer code doesn't use them, but there's still plenty that does. I think that 
it stems primarily from Java programmers expecting them to work as checked 
exceptions and not realizing how they really work. The only thing that will 
likely stop code from breaking where I work due to the deprecation of 
exception specifications is the fact that it'll be years before we use C++11, 
and it'll probably only be newer projects that get compiled that way when it 
_does_ finally happen.

- Jonathan M Davis

Re: Breaking backwards compatiblity

[Walter Bright]

On 3/9/2012 9:14 PM, Andrei Alexandrescu wrote:

On 3/9/12 8:35 PM, Walter Bright wrote:

On 3/9/2012 3:14 PM, bearophile wrote:

D will naturally progressively slow down the rhythm of its new breaking
changes, but even very old languages introduce some breaking changes (see
some of the changes in C++11),


What breaking changes are there in C++11, other than dumping export?


Deprecating exception specifications :o).


I don't think that broke any existing code, because there wasn't any :-)

Consider that I and some others agitated for dumping trigraphs. A couple of 
people voiciferously claimed that their entire code base depended on it, so it 
stayed in.


Never mind that that codebase could be easily accommodated by writing a 
literally trivial filter.


But now, to support raw string literals, C++11 has mucked up trigraphs. It's no 
longer possible to deprecate them without writing a filter that is pretty much a 
full blown C++ compiler itself.

Re: Breaking backwards compatiblity

[Walter Bright]

On 3/9/2012 8:40 PM, Adam D. Ruppe wrote:

On Windows though, even if you relied on bugs twenty
years ago, they bend over backward to keep your app
functioning. It is really an amazing feat they've
accomplished, both from technical and business
perspectives, in doing this while still moving
forward.


I agree that Windows does a better job of it than Linux. MS really does pour 
enormous effort into backwards compatibility. You could legitimately call it 
heroic - and it has paid off for MS.

Re: Can getHash be made pure?

[Walter Bright]

On 3/9/2012 7:21 PM, Martin Nowak wrote:

Bottom-up instead of top-down?


both.

Re: Multiple return values...

[Robert Jacques]

On Fri, 09 Mar 2012 22:16:44 -0600, Andrei Alexandrescu 
 wrote:

On 3/9/12 3:59 PM, Timon Gehr wrote:

Notably, there is no convenient unpacking syntax. Walter does not merge
the patches of Kenji Hara that would fix this because presumably he
fears it could get in the way of a more general solution.


This is because we need to think about that stuff to maximize its
generality.


Was simply applying the unpacking rules to all types (i.e. structs, classes, 
etc) ever considered?

Re: Breaking backwards compatiblity

[Adam D. Ruppe]

On Saturday, 10 March 2012 at 05:15:32 UTC, Andrei Alexandrescu 
wrote:

Why? I have CentOS at work and it seems to work.


My work server is CentOS 5.6 (32 bit), maybe it is this specific
version, but the fresh dmd always gives:

1) a libc version mismatch. I fix this by recompiling from source.

2) a linker error on warn-mismatch or something like that not
   being a valid option. Editing dmd.conf takes care of this one.

Re: Breaking backwards compatiblity

[Andrei Alexandrescu]

On 3/9/12 8:40 PM, Adam D. Ruppe wrote:

(For example, take dmd out of the box on CentOS. Won't
work.)


Why? I have CentOS at work and it seems to work.

Andrei

Re: Breaking backwards compatiblity

[Andrei Alexandrescu]

On 3/9/12 8:46 PM, Adam D. Ruppe wrote:

We might have a stable language, but if the library doesn't
do the same, we'll never be Windows.


I hear ya.

Andrei

Re: Breaking backwards compatiblity

[Andrei Alexandrescu]

On 3/9/12 8:35 PM, Walter Bright wrote:

On 3/9/2012 3:14 PM, bearophile wrote:

D will naturally progressively slow down the rhythm of its new breaking
changes, but even very old languages introduce some breaking changes (see
some of the changes in C++11),


What breaking changes are there in C++11, other than dumping export?


Deprecating exception specifications :o).

Andrei

Re: Arbitrary abbreviations in phobos considered ridiculous

[Andrei Alexandrescu]

On 3/9/12 5:05 PM, Adam D. Ruppe wrote:

On Friday, 9 March 2012 at 23:50:50 UTC, bearophile wrote:

At first I didn't like it a lot because it's cheap syntax sugar that
adds no new power and gives programmers more freedom to write
different-looking versions of the the same code (and this is often bad).


What I like about is the encapsulation benefits. You
don't have to know if the function is a method or an
external function, it just works.

External, non-friend (so separate module in D) functions
are often preferable to methods because they don't have
access to the class' private members, so they cannot rely
on those implementation details.

Extending objects with new functions in this way also
means you don't break binary compatibility with the
existing code, since it isn't modified at all!


Of course, you could always do this with the old
syntax too, but then the syntax preference means
you are biased toward one implementation or the
other - it doesn't mesh as well and you may be
tempted to make things methods for the syntax,
despite the cost in compatibility.

UFCS rox.


Insert obligatory link: http://drdobbs.com/184401197

Very insightful article.


Andrei

Re: Breaking backwards compatiblity

[so]

On Saturday, 10 March 2012 at 00:02:44 UTC, Andrej Mitrovic wrote:

Linus would probably hate D just as much as he hates C++. :p


Rather then using ones influence to make a better language (C) it 
is much easier to bitch about attempts made by others.

Re: Arbitrary abbreviations in phobos considered ridiculous

[Andrei Alexandrescu]

On 3/9/12 4:59 PM, Steven Schveighoffer wrote:

I don't think we should make the default the most conflicting or
difficult to use method. For example, to say:

"always import log using:

import log = std.log"

Is not as good as just not having to say that (i.e. import std.log like
you would any other module). I remember Tango had a couple of modules
like that, and I thought it was pretty confusing.

That doesn't mean you can't utilize those facilities (and I *don't*
discourage them). I just don't think it should be a barrier to usage.


Yah, I'm a bit "ehm" about the sudden recommendation to use named 
import, too. However, I've been "ehm" about similar things in the past 
and came to figure that some things are just useful idioms in the 
forming (e.g. returning locally-defined structs).


I find "import log = std.log" better and using the language more 
naturally than the alternative - a struct/class in conjunction with the 
"stuttering" convention std.log.log.



Andrei

Re: Breaking backwards compatiblity

[Adam D. Ruppe]

On Saturday, 10 March 2012 at 04:40:11 UTC, Adam D. Ruppe wrote:

Yeah, the kernel is decent about it, but the rest of the
system sure as hell isn't.


Let me tie this into D. A couple weeks ago, I revived one of
my work D projects - about 30,000 lines of code - that was
dormant for about a year.

The language worked fine. The library was a bit more of
a pain.

std.date's deprecation still makes me mad.

And the move of std.string.replace over to std.array meant
not one of the modules compiled without a change.

(Really easy change: "import std.string : replace;" why
that works and  "import std.string;" doesn't I'm not sure.
I'm probably relying on a bug here!)



But still, the D language manages to move forward without
much breakage. dmd pretty much gets better each release.


Phobos has some breakage though. Not really bad; updating
this code went quickly. I think I spent half an hour on it.
But, there was some minor changes needed.



We might have a stable language, but if the library doesn't
do the same, we'll never be Windows.

Re: Breaking backwards compatiblity

[Adam D. Ruppe]

On Saturday, 10 March 2012 at 04:34:15 UTC, Walter Bright wrote:
Linux has had a habit of not breaking existing code from 
decades ago. I think that is one reason why it has millions of 
users.


If you want to see someone who takes compatibility
seriously (and all the way to the bank), take a look
at Microsoft Windows.

I don't like developing Linux apps much, nor to a lot
of professionals, because it's binary compatibility is
a joke.

Yeah, the kernel is decent about it, but the rest of the
system sure as hell isn't. You're lucky if you can take
a Linux binary and use it next month, and certainly not
ten years from now.

(For example, take dmd out of the box on CentOS. Won't
work.)


On Windows though, even if you relied on bugs twenty
years ago, they bend over backward to keep your app
functioning. It is really an amazing feat they've
accomplished, both from technical and business
perspectives, in doing this while still moving
forward.

Re: Breaking backwards compatiblity

[Walter Bright]

On 3/9/2012 4:12 PM, Adam D. Ruppe wrote:

The -property switch is a big mistake that breaks a
lot of code.


It was done as a switch to see how much it would break and if that was worth it.

Re: Breaking backwards compatiblity

[Walter Bright]

On 3/9/2012 3:14 PM, bearophile wrote:

D will naturally progressively slow down the rhythm of its new breaking
changes, but even very old languages introduce some breaking changes (see
some of the changes in C++11),


What breaking changes are there in C++11, other than dumping export?

Re: Breaking backwards compatiblity

[Walter Bright]

On 3/9/2012 3:09 PM, Nick Sabalausky wrote:

Keep in mind, too, that Linux has decades of legacy and millions of users.
That's a *very* different situation from Phobos. Apples and oranges.


Linux has had a habit of not breaking existing code from decades ago. I think 
that is one reason why it has millions of users.


Remember, every time you break existing code you reset your user base back to 
zero.

I'm *still* regularly annoyed by the writefln => writeln change in D1 to D2, and 
I agreed to that change. G.

Re: Multiple return values...

[Andrei Alexandrescu]

On 3/9/12 4:10 PM, Timon Gehr wrote:

(int, int) foo(int a, int b){return (a,b);}

assert(foo(foo(foo(foo(1,2==(1,2));

(int, int) goo(int a, int b, int c){return (a+b, c);}

assert(goo(foo(2,3),1) == (5,1));


This is a recipe for disaster because of the implicit expansion. 
Consider forwarding the result of foo to some template. Should the 
template take the tuple type, or automatically expand the tuple and 
accept individual values?


Andrei

Re: Breaking backwards compatiblity

[Walter Bright]

On 3/9/2012 2:56 PM, Jonathan M Davis wrote:

Do you have any specific ones in mind? There were a number of them to try and
make it so that names were more consistent with regards to camelcasing and the
like, but those changes have largely stopped (or at least are well into the
deprecation process if they haven't been completed yet).


I've voiced my objections to changing those names before. I know it's a done 
deal now.

Re: Breaking backwards compatiblity

[Walter Bright]

On 3/9/2012 4:02 PM, Andrej Mitrovic wrote:

Linus would probably hate D just as much as he hates C++. :p


It's clear to me from Linus' postings that he would not be interested in D. And 
that's ok. He's doing what works for him, and it's hard to argue with his 
success at it.

Re: Annotations or custom attributes

[Andrei Alexandrescu]

On 3/9/12 4:24 PM, Steven Schveighoffer wrote:

On Fri, 09 Mar 2012 19:05:00 -0500, Ary Manzana 
wrote:


What are you talking about?


Who are you talking to?

:)

Seriously, though, I think Andrej sometimes quotes *nothing* (no offense
for picking on you Andrej), and couple that with the newsgroup's
seemingly random decision to start a new thread, or put a reply at the
same level, I sometimes have no idea what he's talking about :)


There are extremes, of course. I, for one, take pains to make sure I 
quote about the "right" amount of context. I know it's time well spent 
because every second I save for one reader is multiplied by many of 
them. I think it's very jarring to see a 300-line discussion quoted and 
followed by a brief answer. If that much context is necessary, I'd have 
no business reading that message unless I actually followed the 
conversation.


Andrei

Re: Multiple return values...

[Andrei Alexandrescu]

On 3/9/12 3:59 PM, Timon Gehr wrote:

Yes, but we wouldn't have needed it if the built-in one would have been
considered sufficient.


The goal is considering the language sufficient for implementing a 
useful structure such as Tuple in a library. Same goes about associative 
arrays.



- Returning it from a function is not efficient.


Implementation issue, if at all. Solving that will optimize the return 
of any structure in any D code.



- It does not play very nicely with type deduction.


It plays by the rules enacted by the D programming language. If those 
aren't nice, there's a problem with them rules. If you like them rules 
but want "special" rules for templates, you're asking for magic. Magic 
smells.



- It has clumsy syntax and is therefore rarely used.


Then templates have clumsy syntax and therefore are rarely used.


Notably, there is no convenient unpacking syntax. Walter does not merge
the patches of Kenji Hara that would fix this because presumably he
fears it could get in the way of a more general solution.


This is because we need to think about that stuff to maximize its 
generality.



- It is a trivial wrapper for an underpowered built-in type. This causes
confusion.


It's not quite trivial.


This situation is neither particularly pragmatic nor pure enough. I'd
call it a wart.


I'd call it a great artifact. Love the Tuple (and the Drake).


Andrei

Re: Breaking backwards compatiblity

[Adam D. Ruppe]

On Saturday, 10 March 2012 at 03:33:42 UTC, Mantis wrote:

What should be the type of a?


int. I'm for using @property to disambiguate
in any case.

That's a clear benefit.

I'm against the strict enforcement where it
forces you to choose parens or no parens at
the declaration site (what -property does).
That's just pointless bikeshedding that
breaks perfectly good code.

Re: Breaking backwards compatiblity

[Mantis]

10.03.2012 3:01, Adam D. Ruppe пишет:

On Saturday, 10 March 2012 at 00:48:56 UTC, Jonathan M Davis wrote:

From the  sounds of it, Adam thinks that it's bad


Indeed. I have an advantage here though: it is an
objective fact that -property breaks a lot of existing
D code.

We can (and have) argue(d) all day about what, if
any, improvements strict enforcement actually brings.


Arguments are same as before, I believe:
//
alias int delegate() dg_t;

@property dg_t foo() {
return { return 42; };
}

int main() {
auto a = foo();
return 0;
}
//
What should be the type of a?

Re: Breaking backwards compatiblity

[ludi]

On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
This statement is from Linus Torvalds about breaking binary 
compatibility:


https://lkml.org/lkml/2012/3/8/495

While I don't think we need to worry so much at the moment 
about breaking binary compatibility with new D releases, we do 
have a big problem with breaking source code compatibility.


This is why we need to have a VERY high bar for breaking 
changes.


I don't think it is that straightforward to conclude anything
about source compatibility in a programming language from this
argument about binary compatibility in a kernel.

Re: forum.dlang.org thread lovers suggested change

[Steven Schveighoffer]

On Fri, 09 Mar 2012 21:50:47 -0500, H. S. Teoh   
wrote:



2) Web forum interfaces suck. I've yet to see one that doesn't.


http://forum.dlang.org/set?url=%2Fgroup%2Fdigitalmars%2ED&secret=ueonfyyrxqnhpkuddoaz&groupviewmode=threaded

Best web forum interface I've ever used (and it's as fast as my mail  
client).


Also try the horizontal-split view (link at the top).

-Steve

Re: Can getHash be made pure?

[Martin Nowak]

On Sat, 10 Mar 2012 03:18:59 +0100, Walter Bright  
 wrote:



On 3/9/2012 5:15 PM, H. S. Teoh wrote:

I tried to make getHash() const pure nothrow @safe, but found that in
some places it calls toHash() which isn't marked const pure nothrow
@safe.  So I fixed that as well, then found that toHash() calls
toString() which isn't pure, nothrow, nor @safe... and before I knew it,
I was deep into marking a *lot* of druntime functions (as perhaps they
*should* be), and then I ran into this:

src/object_.d(648): Error: function  
object.TypeInfo_AssociativeArray.next () is not callable using argument  
types ()
src/object_.d(648): Error: function  
object.TypeInfo_AssociativeArray.next () is not callable using argument  
types ()
src/object_.d(759): Error: function object.TypeInfo_Class.info () is  
not callable using argument types ()

src/object_.d(1334): Error: cannot uniquely infer foreach argument types
src/core/runtime.d(483): Error: cannot uniquely infer foreach argument  
types

make: *** [lib/libdruntime-linux32.a] Error 1


Yeah, I know, it's viral. Can't do it piecemeal.


Bottom-up instead of top-down?

Re: Breaking backwards compatiblity

[Martin Nowak]

On Fri, 09 Mar 2012 23:32:58 +0100, Walter Bright  
 wrote:


This statement is from Linus Torvalds about breaking binary  
compatibility:


https://lkml.org/lkml/2012/3/8/495

While I don't think we need to worry so much at the moment about  
breaking binary compatibility with new D releases, we do have a big  
problem with breaking source code compatibility.


This is why we need to have a VERY high bar for breaking changes.


Definitely.
I think we should gather bugs that require breaking changes and prioritize  
them.


IMHO it's also the main reason to continue fixing imports and protection.  
By now
people mostly still appreciate those fixes but the pain they cause will  
only ever grow.


ABI
http://d.puremagic.com/issues/show_bug.cgi?id=7469

Re: forum.dlang.org thread lovers suggested change

[H. S. Teoh]

On Sat, Mar 10, 2012 at 03:22:26AM +0100, Jesse Phillips wrote:
> After much use of the new NNTP reader I'd like to suggest a change
> that I hope other users of "Thread" may also desire.
> 
> The software is set up with this kind of hierarchy
> 
> Group List
> Message List
> Message
> 
> There are three views, Basic, Thread, Horizontal-split. To improve the
> experience of using Threads I would like to see the Message List to be
> in the same for as Basic.

I'm not sure what you're referring to, are you using the website
interface for the forums?


> Clicking on the descussion would bring you to the first post, but
> clicking the cool (30 new) brings you to the first new post (based on
> time or position, don't care).
> 
> The Horizontal-split would no longer include all of the descussions,
> only the one you are viewing.
> 
> Any opinions of those who also prefer threading over unorder reading?

1) Threading is a must to keep up with a high-volume forum like this
one.

2) Web forum interfaces suck. I've yet to see one that doesn't. (Doesn't
mean a good one can't be made though. I just haven't seen it yet.) I
personally use Mutt with the mailing list. Highly recommended. A real
NNTP reader like rn or tin is also recommended.

3) A *real* threading interface needs to show you the entire thread
*tree*, not just some randomly linearized form of it (like most web
interfaces do). Anything less than the full discussion tree will
inevitably bring confusion and disorder to the discussion. Like some
arbitrary 3-level hierarchy of messages.

4) A *real* threading interface must also allow replying to a specific
node in the tree (by setting References: and In-Reply-To: properly), not
just randomly tack on your response to the bottom of the thread, thus
breaking up the structure of the discussion and causing needless
confusion.

5) A *real* threading interface needs to let you manage subthreads in a
sane way. E.g., expand/collapse subtrees, hide a subtree or an entire
thread, mark a (sub)tree as read, etc..  Otherwise a large thread (with
complex branching structure) will become unnavigable, and people will be
liable to just post replies to random nodes at the bottom of the tree
instead of the subtree where it belongs, again breaking up the threading
structure and leading to general confusion.

Most people may or may not agree with everything I said. :-)


T

-- 
What doesn't kill me makes me stranger.

Re: forum.dlang.org thread lovers suggested change

[Jonathan M Davis]

On Saturday, March 10, 2012 03:22:26 Jesse Phillips wrote:
> After much use of the new NNTP reader I'd like to suggest a
> change that I hope other users of "Thread" may also desire.
> 
> The software is set up with this kind of hierarchy
> 
> Group List
>  Message List
>  Message
> 
> There are three views, Basic, Thread, Horizontal-split. To
> improve the experience of using Threads I would like to see the
> Message List to be in the same for as Basic.
> 
> Clicking on the descussion would bring you to the first post, but
> clicking the cool (30 new) brings you to the first new post
> (based on time or position, don't care).
> 
> The Horizontal-split would no longer include all of the
> descussions, only the one you are viewing.
> 
> Any opinions of those who also prefer threading over unorder
> reading?

I would definitely consider that to be a negative. "Threaded" has it right as 
far as I'm concerned. However, I use my e-mail client primarily, so I'm not 
normally one of the users of the web interface.

- Jonathan M Davis

Re: forum.dlang.org thread lovers suggested change

[Vladimir Panteleev]

On Saturday, 10 March 2012 at 02:22:27 UTC, Jesse Phillips wrote:
The Horizontal-split would no longer include all of the 
descussions, only the one you are viewing.


Personally I don't like this idea, since the view mode is 
supposed to mimic newsreader software. It'll also prevent being 
able to get an overview of new posts in threads and subthreads at 
a glance (or scroll). What you describe sounds a lot like Google 
Groups, though, so it might make sense as an option or another 
view mode.

forum.dlang.org thread lovers suggested change

[Jesse Phillips]

After much use of the new NNTP reader I'd like to suggest a 
change that I hope other users of "Thread" may also desire.


The software is set up with this kind of hierarchy

Group List
Message List
Message

There are three views, Basic, Thread, Horizontal-split. To 
improve the experience of using Threads I would like to see the 
Message List to be in the same for as Basic.


Clicking on the descussion would bring you to the first post, but 
clicking the cool (30 new) brings you to the first new post 
(based on time or position, don't care).


The Horizontal-split would no longer include all of the 
descussions, only the one you are viewing.


Any opinions of those who also prefer threading over unorder 
reading?

Re: Can getHash be made pure?

[Walter Bright]

On 3/9/2012 5:15 PM, H. S. Teoh wrote:

I tried to make getHash() const pure nothrow @safe, but found that in
some places it calls toHash() which isn't marked const pure nothrow
@safe.  So I fixed that as well, then found that toHash() calls
toString() which isn't pure, nothrow, nor @safe... and before I knew it,
I was deep into marking a *lot* of druntime functions (as perhaps they
*should* be), and then I ran into this:

src/object_.d(648): Error: function object.TypeInfo_AssociativeArray.next () is 
not callable using argument types ()
src/object_.d(648): Error: function object.TypeInfo_AssociativeArray.next () is 
not callable using argument types ()
src/object_.d(759): Error: function object.TypeInfo_Class.info () is not 
callable using argument types ()
src/object_.d(1334): Error: cannot uniquely infer foreach argument types
src/core/runtime.d(483): Error: cannot uniquely infer foreach argument types
make: *** [lib/libdruntime-linux32.a] Error 1


Yeah, I know, it's viral. Can't do it piecemeal.



A related question though: have we implemented automatic propagation of
attributes like pure/nothrow/etc., yet? Just wondering if I can just
modify the base class and have the attributes propagate, or I have to
search for every override of every affected function in order to mark
them (as I have been doing -- just wanted to make sure it isn't for
nothing).


For 2.059, yes.

Re: Arbitrary abbreviations in phobos considered ridiculous

[H. S. Teoh]

On Sat, Mar 10, 2012 at 02:05:38AM +0100, Adam D. Ruppe wrote:
[...]
> What I like about is the encapsulation benefits. You
> don't have to know if the function is a method or an
> external function, it just works.
> 
> External, non-friend (so separate module in D) functions
> are often preferable to methods because they don't have
> access to the class' private members, so they cannot rely
> on those implementation details.
> 
> Extending objects with new functions in this way also
> means you don't break binary compatibility with the
> existing code, since it isn't modified at all!
> 
> 
> Of course, you could always do this with the old
> syntax too, but then the syntax preference means
> you are biased toward one implementation or the
> other - it doesn't mesh as well and you may be
> tempted to make things methods for the syntax,
> despite the cost in compatibility.
> 
> UFCS rox.

+1. Thanks for bringing this up; this is a very significant benefit.  It
makes it possible for you to adapt a class which you can't change (e.g.,
shipped as a binary-only library) to work with, say, templates that
expect certain class members that aren't there but can be implemented
using what is available.  UFCS makes this possible without lots of
bandaging, mummy-wrapping, or special-casing that adds lots of bloat to
template code.

UFCS also makes it possible to implement operator overloading to make
diverse types work nicely with each other (esp. if you're importing
multiple numerical libraries that don't know of each other's existence).


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond

Re: Multiple return values...

[Manu]

On 10 March 2012 02:10, Timon Gehr  wrote:

> On 03/10/2012 01:00 AM, Manu wrote:
>
>> On 10 March 2012 01:17, Timon Gehr > > wrote:
>>
>>On 03/10/2012 12:02 AM, Manfred Nowak wrote:
>>
>>Manu wrote:
>>
>>I'm just talking about the ABI for returning multiple
>>values, not
>>chaining
>>
>>
>>Does this mean, that you want a special type of "function"? For
>>example
>>this would be disallowed statement: `auto result= f( g(
>>parameters));',
>>if `f' and `g' are functions returning multiple values?
>>
>>
>>This needs to work. Multiple return values should integrate with the
>>existing language support for tuples.
>>
>>
>> What should that do exactly? A function that returns multiple values is
>> passed as an argument to another function... what exactly is fed to
>> which arguments of the outer function?
>>
>
> It would work like built-in tuples already do.
>
> (int, int) foo(int a, int b){return (a,b);}
>
> assert(foo(foo(foo(foo(1,2**==(1,2));
>
> (int, int) goo(int a, int b, int c){return (a+b, c);}
>
> assert(goo(foo(2,3),1) == (5,1));
>
>
>
>  Describe how you see multiple return values working through tuples,
>> while satisfying the issues I raise in my first couple of posts?
>>
>
> I have done so in my other post, you may refer to that one if something is
> still unclear: 
> http://forum.dlang.org/post/**jjdhdk$16v3$1...@digitalmars.com
>

Right, that all looks good.
But I'm unclear of the language semantics, is this built-in a tuple
actually a physical struct like phobos Tuple, or is it strictly a higher
level concept?
I didn't realise such a thing as 'built-in tuple' existed, why does phobos
Tuple exist?

Re: Annotations or custom attributes

[Andrej Mitrovic]

On 3/10/12, Steven Schveighoffer  wrote:
> I hope you realize I didn't mean it in a bad/condescending way :)

No problemo! I don't take things too seriously around this place (or
the internets in general).

> But whose fault is it?

I'd say it's the technology's fault. A newsgroup seems to be the
equivalent of a source file, but with each person having a compiler
with different semantics. Related:
http://www.youtube.com/watch?v=Fc1P-AEaEp8

Re: Annotations or custom attributes

[H. S. Teoh]

On Fri, Mar 09, 2012 at 08:07:47PM -0500, Steven Schveighoffer wrote:
> On Fri, 09 Mar 2012 19:58:37 -0500, H. S. Teoh
>  wrote:
> 
> >On Fri, Mar 09, 2012 at 07:24:34PM -0500, Steven Schveighoffer wrote:
> >>Seriously, though, I think Andrej sometimes quotes *nothing* (no
> >>offense for picking on you Andrej), and couple that with the
> >>newsgroup's seemingly random decision to start a new thread, or put
> >>a reply at the same level, I sometimes have no idea what he's
> >>talking about :)
> >[...]
> >
> >You guys should just use a threading mail reader. Like mutt. :-P :-P
> >(Though Ary's post didn't make sense to me either, because I'd
> >deleted the parent post already. Ah well. The joys of impersonal
> >online communication...)
> 
> You should not delete old posts :)  I find it invaluable for searching
> for old discussions sometimes (I use opera with google-like
> searching).
[...]

While I agree with you on principle, after having accumulated YEARS of
archives for several high-volume mailing lists in the past I'm starting
to doubt the value of doing it. Sometimes the signal-to-noise ratio is
just too low to justify archiving *everything*. So I usually only save
threads that I find interesting and has lasting value and delete the
rest (esp. since there's an online archive for it anyway).


T

-- 
In a world without fences, who needs Windows and Gates? -- Christian Surchi

Re: Breaking backwards compatiblity

[Steven Schveighoffer]

On Fri, 09 Mar 2012 20:04:49 -0500, H. S. Teoh   
wrote:



On Fri, Mar 09, 2012 at 07:51:12PM -0500, Steven Schveighoffer wrote:

On Fri, 09 Mar 2012 19:40:37 -0500, H. S. Teoh
 wrote:

>On Fri, Mar 09, 2012 at 07:26:48PM -0500, Steven Schveighoffer wrote:

>>(dons flame war proof suit)
>[...]
>
>I don't see what's there to flamewar about.

You're new...

:)

[...]

Not nearly new enough to not be partially responsible for that huge
gigantic thread about exceptions. :-) (Which I had no trouble following,
btw, even though it's clear that a lot of people were totally lost after
the first 100 posts or so. Mutt is just *that* cool. OTOH, when the
thread nesting depth exceeded even mutt's ability to display the thread
lines (because it was overflowing my terminal width), the thread started
to fizzle out. I'm guessing that's when the rest of us mutt users bailed
out. :-P)



No, what I meant is that @property is a sore subject that invariable  
starts a time-consuming never-winning flame war any time someone mentions  
how it should or shouldn't be mandatory.


-Steve

Re: Can getHash be made pure?

[H. S. Teoh]

On Fri, Mar 09, 2012 at 02:01:01PM -0800, Walter Bright wrote:
> On 3/9/2012 1:54 PM, H. S. Teoh wrote:
> >Still chugging away at implementing AA's in druntime proper, I reviewed
> >the code for methods that can be marked pure but ran into a major road
> >block: getHash() is not marked pure. That makes a lot of AA methods
> >impure, that could, and probably should, be marked pure.
> >
> >Is it possible to make TypeInfo.getHash() pure? AFAICT there's no good
> >reason why it shouldn't be pure. Am I missing something?
> 
> It should be const, pure, nothrow, @safe.

Hmph.

I tried to make getHash() const pure nothrow @safe, but found that in
some places it calls toHash() which isn't marked const pure nothrow
@safe.  So I fixed that as well, then found that toHash() calls
toString() which isn't pure, nothrow, nor @safe... and before I knew it,
I was deep into marking a *lot* of druntime functions (as perhaps they
*should* be), and then I ran into this:

src/object_.d(648): Error: function object.TypeInfo_AssociativeArray.next () is 
not callable using argument types ()
src/object_.d(648): Error: function object.TypeInfo_AssociativeArray.next () is 
not callable using argument types ()
src/object_.d(759): Error: function object.TypeInfo_Class.info () is not 
callable using argument types ()
src/object_.d(1334): Error: cannot uniquely infer foreach argument types
src/core/runtime.d(483): Error: cannot uniquely infer foreach argument types
make: *** [lib/libdruntime-linux32.a] Error 1

I'm not sure how to proceed from here.

A related question though: have we implemented automatic propagation of
attributes like pure/nothrow/etc., yet? Just wondering if I can just
modify the base class and have the attributes propagate, or I have to
search for every override of every affected function in order to mark
them (as I have been doing -- just wanted to make sure it isn't for
nothing).


T

-- 
It won't be covered in the book. The source code has to be useful for
something, after all. -- Larry Wall

Re: Annotations or custom attributes

[Steven Schveighoffer]

On Fri, 09 Mar 2012 19:58:37 -0500, H. S. Teoh   
wrote:



On Fri, Mar 09, 2012 at 07:24:34PM -0500, Steven Schveighoffer wrote:

Seriously, though, I think Andrej sometimes quotes *nothing* (no
offense for picking on you Andrej), and couple that with the
newsgroup's seemingly random decision to start a new thread, or put
a reply at the same level, I sometimes have no idea what he's
talking about :)

[...]

You guys should just use a threading mail reader. Like mutt. :-P :-P
(Though Ary's post didn't make sense to me either, because I'd deleted
the parent post already. Ah well. The joys of impersonal online
communication...)


You should not delete old posts :)  I find it invaluable for searching for  
old discussions sometimes (I use opera with google-like searching).


-Steve

Re: Arbitrary abbreviations in phobos considered ridiculous

[Adam D. Ruppe]

On Friday, 9 March 2012 at 23:50:50 UTC, bearophile wrote:
At first I didn't like it a lot because it's cheap syntax sugar 
that adds no new power and gives programmers more freedom to 
write different-looking versions of the the same code (and this 
is often bad).


What I like about is the encapsulation benefits. You
don't have to know if the function is a method or an
external function, it just works.

External, non-friend (so separate module in D) functions
are often preferable to methods because they don't have
access to the class' private members, so they cannot rely
on those implementation details.

Extending objects with new functions in this way also
means you don't break binary compatibility with the
existing code, since it isn't modified at all!


Of course, you could always do this with the old
syntax too, but then the syntax preference means
you are biased toward one implementation or the
other - it doesn't mesh as well and you may be
tempted to make things methods for the syntax,
despite the cost in compatibility.

UFCS rox.

Re: Annotations or custom attributes

[Steven Schveighoffer]

On Fri, 09 Mar 2012 19:53:29 -0500, Andrej Mitrovic  
 wrote:



On 3/10/12, Steven Schveighoffer  wrote:

Seriously, though, I think Andrej sometimes quotes *nothing* (no offense
for picking on you Andrej), and couple that with the newsgroup's  
seemingly
random decision to start a new thread, or put a reply at the same  
level, I

sometimes have no idea what he's talking about :)


LOL. I was honestly wondering if this was an issue or not. I blame the
gmail quick-reply box. It has two options: quote everything, or quote
nothing. Otherwise there's a full reply button and then I can quickly
select a piece of text to quote. But I *thought* that by using quick
reply without fully quoting it would mean my reply would sit right
next to the last poster's reply.


I think it does, actually.  It's just the post you are responding to isn't  
always the last poster :D



I'm just used to using forum software and when I do a quick-reply
there my post is right below the last user's post, and it's easy to
figure out who I'm replying to.


The forum software does not by default thread discussions, but my  
newsreader does.



Anyway, I'll stop posting replies to the void. :p (thanks for letting
me know btw)


I hope you realize I didn't mean it in a bad/condescending way :)  I  
realize we all use software that sometimes doesn't do the right thing, and  
it's not always our fault for liking some shitty software.


But whose fault is it?  Yours for using a forum-like software, or mine for  
trying to thread the newsgroup?  If a tree posts a reply in the wrong  
thread, and the forest doesn't use threading readers, does anyone care?


-Steve

Re: Breaking backwards compatiblity

[Adam D. Ruppe]

On Saturday, 10 March 2012 at 00:48:56 UTC, Jonathan M Davis 
wrote:

From the  sounds of it, Adam thinks that it's bad


Indeed. I have an advantage here though: it is an
objective fact that -property breaks a lot of existing
D code.

We can (and have) argue(d) all day about what, if
any, improvements strict enforcement actually brings.

Re: Arbitrary abbreviations in phobos considered ridiculous

[Steven Schveighoffer]

On Fri, 09 Mar 2012 19:32:06 -0500, David Nadlinger   
wrote:



On Friday, 9 March 2012 at 23:39:25 UTC, Steven Schveighoffer wrote:
I want to stress again the difference between C++'s namespaces, and D's  
module import mechanism.  In C++, you *deliberately* pull a namespace  
into your scope (and usually only in the implementation file, which  
doesn't affect any other implementation files), whereas in D, a  
standard "import std.datetime" *automatically* pulls its namespace into  
your scope, and any public imports it has made.


To be honest, I don't quite see the big difference here. Just as you can  
only #include a »namespaced« file without using a using directive, you  
can »static import« a module in D. You seem to be arguing that we  
shouldn't encourage use of these features (cf. the std.log discussion),  
but I can't quite follow you there.


The big difference is, the most straightforward and most exemplified  
import syntax is:


import modulename;

So to argue this is not the default syntax, or not the most desirable/used  
syntax is just plain invalid.


In contrast, C++'s import syntax is:

#include "modulename.h"

which does not import any namespaces into your scope.

Why would _not_ using static and selective imports be desirable? Don't  
we generally discourage people from write »using namespace std« in C++  
or »import *« in Python as well? (I'm aware that the D module system is  
different, but the general idea is the same)


I don't think we should make the default the most conflicting or difficult  
to use method.  For example, to say:


"always import log using:

import log = std.log"

Is not as good as just not having to say that (i.e. import std.log like  
you would any other module).  I remember Tango had a couple of modules  
like that, and I thought it was pretty confusing.


That doesn't mean you can't utilize those facilities (and I *don't*  
discourage them).  I just don't think it should be a barrier to usage.


-Steve

Re: Breaking backwards compatiblity

[H. S. Teoh]

On Fri, Mar 09, 2012 at 07:51:12PM -0500, Steven Schveighoffer wrote:
> On Fri, 09 Mar 2012 19:40:37 -0500, H. S. Teoh
>  wrote:
> 
> >On Fri, Mar 09, 2012 at 07:26:48PM -0500, Steven Schveighoffer wrote:
> 
> >>(dons flame war proof suit)
> >[...]
> >
> >I don't see what's there to flamewar about.
> 
> You're new...
> 
> :)
[...]

Not nearly new enough to not be partially responsible for that huge
gigantic thread about exceptions. :-) (Which I had no trouble following,
btw, even though it's clear that a lot of people were totally lost after
the first 100 posts or so. Mutt is just *that* cool. OTOH, when the
thread nesting depth exceeded even mutt's ability to display the thread
lines (because it was overflowing my terminal width), the thread started
to fizzle out. I'm guessing that's when the rest of us mutt users bailed
out. :-P)


T

-- 
"Outlook not so good." That magic 8-ball knows everything! I'll ask
about Exchange Server next. -- (Stolen from the net)

covariance of 'out' parameters is crucial for polymorphism and function subtyping

[Boscop]

I noticed that D doesn't support covariant 'out' parameters, 
which breaks polymorphism that involves such functions, e.g.:

---
// these classes' foo method returns via return value
class A {A foo(){return new A;}}
class B : A {B foo(){return new B;}}

// these classes' foo method returns via out args
class AA {void foo(out AA a){a = new AA;}}
class BB : AA {void foo(out BB b){b = new BB;}}
// Error: class BB use of AA.foo(out AA a) hidden by BB is 
deprecated


void main() {
// these work
A a2, a = new A;
a2 = a.foo();
B b2, b = new B;
b2 = b.foo();

// these don't work because of the above error
AA aa2, aa = new AA;
aa.foo(aa2);
BB bb2, bb = new BB;
bb.foo(bb2);
}
---
Further examples and description of the implications can be found 
in the bug report: 
http://d.puremagic.com/issues/show_bug.cgi?id=7676


It is crucial for function subtyping, because functions are only 
contravariant in their 'in' parameters, but covariant in their 
'out' parameters and return type.
Function subtyping matters not only in classes with methods that 
have 'out' parameters but also when assigning functions to 
function pointers or passing functions as argument to other 
functions.


I don't think this counts as an enhancement, it's definitely a 
design bug, and there is no reason why it should not be fixed now.
This should not be harder to implement than covariance for return 
types (which is already implemented) and wouldn't break any code.

Re: Annotations or custom attributes

[H. S. Teoh]

On Fri, Mar 09, 2012 at 07:24:34PM -0500, Steven Schveighoffer wrote:
> On Fri, 09 Mar 2012 19:05:00 -0500, Ary Manzana
>  wrote:
> 
> >What are you talking about?
> 
> Who are you talking to?
> 
> :)
> 
> Seriously, though, I think Andrej sometimes quotes *nothing* (no
> offense for picking on you Andrej), and couple that with the
> newsgroup's seemingly random decision to start a new thread, or put
> a reply at the same level, I sometimes have no idea what he's
> talking about :)
[...]

You guys should just use a threading mail reader. Like mutt. :-P :-P
(Though Ary's post didn't make sense to me either, because I'd deleted
the parent post already. Ah well. The joys of impersonal online
communication...)


T

-- 
I see that you JS got Bach.

Re: Breaking backwards compatiblity

[Steven Schveighoffer]

On Fri, 09 Mar 2012 19:40:37 -0500, H. S. Teoh   
wrote:



On Fri, Mar 09, 2012 at 07:26:48PM -0500, Steven Schveighoffer wrote:



(dons flame war proof suit)

[...]

I don't see what's there to flamewar about.


You're new...

:)

-Steve

Re: inout and function/delegate parameters

[Steven Schveighoffer]

On Fri, 09 Mar 2012 19:44:20 -0500, Stewart Gordon   
wrote:



On 19/02/2012 14:27, Stewart Gordon wrote:


int opApply(int delegate(ref inout(T)) dg) inout;

But then I realised a potential ambiguity:
(a) the constancy is passed through to the delegate
(b) the delegate has an inout parameter in its own right



Thinking about it, if we go with (a), then (b) can be achieved by  
defining an alias of the delegate type.  Just one problem I can see:  
since a signature that uses (b) can't be represented in code without an  
alias, how would compiler messages, .stringof and TypeInfo notate the  
type?


But if we go with (b), then there doesn't seem to be a way to achieve  
(a) without inventing new syntax.


As I recently mentioned in the bug report, (b) must be the case without  
any additional syntax, because otherwise you have two types with identical  
syntax, but different underlying types.


In order to do (a), we need new syntax.  That's not a good thing, but not  
the end of the world.


-Steve

Re: Arbitrary abbreviations in phobos considered ridiculous

[H. S. Teoh]

On Sat, Mar 10, 2012 at 01:43:35AM +0100, Timon Gehr wrote:
> On 03/10/2012 01:10 AM, H. S. Teoh wrote:
> >On Fri, Mar 09, 2012 at 06:50:50PM -0500, bearophile wrote:
> >>Jonathan M Davis:
> >>
> >>>I don't know what the current state of UFCS is.
> >>
> >>I have found a possible problem in it, and probably there are some
> >>missing parts, but it's working well.
> >
> >I found that x.foo doesn't work, it needs to be x.foo(). But we're
> >deprecating omission of parentheses of non-@property functions anyway,
> >and an external function can hardly be a @property of anything, so I
> >don't think this needs to be fixed.
> >
> 
> UFCS for @properties seems to work according to the unit tests.
> However, this makes @property ambiguous. foo = 2 will be the same as
> 2.foo.

But 2.foo can never be interpreted as obj.foo = 2. I can't imagine any
way to write 2.something and have it come out as obj.foo(2).

The only remote possibility is inside a class/struct method, but in that
case doesn't class/struct scope take precedence anyway? And presumably,
you wouldn't be using pseudo-members if you're the one writing the
class.  Otherwise, if the programmer is deliberately trying to break the
system, well, he shouldn't be surprised if things break. :-)


T

-- 
Тише едешь, дальше будешь.

Re: Annotations or custom attributes

[Andrej Mitrovic]

On 3/10/12, Steven Schveighoffer  wrote:
> Seriously, though, I think Andrej sometimes quotes *nothing* (no offense
> for picking on you Andrej), and couple that with the newsgroup's seemingly
> random decision to start a new thread, or put a reply at the same level, I
> sometimes have no idea what he's talking about :)

LOL. I was honestly wondering if this was an issue or not. I blame the
gmail quick-reply box. It has two options: quote everything, or quote
nothing. Otherwise there's a full reply button and then I can quickly
select a piece of text to quote. But I *thought* that by using quick
reply without fully quoting it would mean my reply would sit right
next to the last poster's reply.

I'm just used to using forum software and when I do a quick-reply
there my post is right below the last user's post, and it's easy to
figure out who I'm replying to.

Anyway, I'll stop posting replies to the void. :p (thanks for letting
me know btw)

Re: Arbitrary abbreviations in phobos considered ridiculous

[Timon Gehr]

On 03/10/2012 01:22 AM, David Nadlinger wrote:

On Saturday, 10 March 2012 at 00:16:14 UTC, Jonathan M Davis wrote:

UFCS will give people more freedom and may help templates in
some cases, […]


Note aside: I think people tend to overestimate the amount of generic
code that becomes easier to write


If you're writing it yourself there are no restrictions on what symbols 
can be made visible.


/extend

This OTOH is a valid point.


with UFCS, as D, in contrast to
C++, doesn't have ADL.



This is a good thing. D symbol lookup is already the most complicated 
I've seen (for the compiler). DMD does not get it right. It is possible 
to write programs whose semantics depend on the order the modules are 
passed on the command line.

Re: Breaking backwards compatiblity

[Jonathan M Davis]

On Friday, March 09, 2012 16:40:37 H. S. Teoh wrote:
> On Fri, Mar 09, 2012 at 07:26:48PM -0500, Steven Schveighoffer wrote:
> > On Fri, 09 Mar 2012 19:12:34 -0500, Adam D. Ruppe
> > 
> >  wrote:
> > >On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
> > >>This is why we need to have a VERY high bar for breaking changes.
> > >
> > >Please remember this if someone proposes enforcing
> > >@property by default.
> 
> I propose enabling @property by default.
> 
> > Clears the bar with room to spare IMO.
> > 
> > Not to mention it's not just a proposal, but in print in TDPL .
> > 
> > (dons flame war proof suit)
> 
> [...]
> 
> I don't see what's there to flamewar about. AFAIK @property enforcement
> is going to happen sooner or later.

Yes. The problem is that some people don't like @property and don't want it 
enforced, whereas others think it's a big improvement. From the sounds of it, 
Adam thinks that it's bad, whereas Steven thinks that it's good. Personally, 
I'm _definitely_ in favor of property enforcement.

Regardless, it's in TDPL, and the current plan is to enforce it. It just 
hasn't reached that point yet, since we're still in the transition stage from 
not having @property at all to having @property and having it enforced.

- Jonathan M Davis

Re: inout and function/delegate parameters

[Stewart Gordon]

On 19/02/2012 14:27, Stewart Gordon wrote:


int opApply(int delegate(ref inout(T)) dg) inout;

But then I realised a potential ambiguity:
(a) the constancy is passed through to the delegate
(b) the delegate has an inout parameter in its own right



Thinking about it, if we go with (a), then (b) can be achieved by defining an alias of the 
delegate type.  Just one problem I can see: since a signature that uses (b) can't be 
represented in code without an alias, how would compiler messages, .stringof and TypeInfo 
notate the type?


But if we go with (b), then there doesn't seem to be a way to achieve (a) without 
inventing new syntax.


Stewart.

Re: Arbitrary abbreviations in phobos considered ridiculous

[Timon Gehr]

On 03/10/2012 01:10 AM, H. S. Teoh wrote:

On Fri, Mar 09, 2012 at 06:50:50PM -0500, bearophile wrote:

Jonathan M Davis:


I don't know what the current state of UFCS is.


I have found a possible problem in it, and probably there are some
missing parts, but it's working well.


I found that x.foo doesn't work, it needs to be x.foo(). But we're
deprecating omission of parentheses of non-@property functions anyway,
and an external function can hardly be a @property of anything, so I
don't think this needs to be fixed.



UFCS for @properties seems to work according to the unit tests.
However, this makes @property ambiguous. foo = 2 will be the same as 2.foo.

Re: Arbitrary abbreviations in phobos considered ridiculous

[H. S. Teoh]

On Fri, Mar 09, 2012 at 07:32:55PM -0500, Jonathan M Davis wrote:
> On Saturday, March 10, 2012 01:22:49 David Nadlinger wrote:
> > On Saturday, 10 March 2012 at 00:16:14 UTC, Jonathan M Davis wrote:
> > > UFCS will give people more freedom and may help templates in
> > > some cases, […]
[...]
> So, it'll probably help _some_, but I think that there's a good chance
> that you're right and that it won't be as useful as some people are
> expecting. But for better or worse, it looks like we're getting it.
[...]

We already have it. Latest DMD in git understands stuff like 2.5.sqrt(),
and supports pseudo-members.


T

-- 
A program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the potential for it to be applied to tasks that are
conceptually similar and, more important, to tasks that have not yet
been conceived. -- Michael B. Allen

Re: Breaking backwards compatiblity

[Adam D. Ruppe]

On Saturday, 10 March 2012 at 00:25:23 UTC, Jonathan M Davis 
wrote:
As I understand it, it's like override, it's being phased in, 
and it _will_ become the normal behavior.


A planned or inevitable big mistake that will break piles
of code in a painful way is still a big mistake that will
break piles of code in a painful way.


and @property _do_ pass the very high bar.


If the height of the bar is based on how much code it
breaks, sure.

If it based on the benefit it actually brings us, no,
absolutely not.

@property is the biggest name bikeshed of them all.

Re: Breaking backwards compatiblity

[H. S. Teoh]

On Fri, Mar 09, 2012 at 07:26:48PM -0500, Steven Schveighoffer wrote:
> On Fri, 09 Mar 2012 19:12:34 -0500, Adam D. Ruppe
>  wrote:
> 
> >On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
> >>This is why we need to have a VERY high bar for breaking changes.
> >
> >Please remember this if someone proposes enforcing
> >@property by default.

I propose enabling @property by default.


> Clears the bar with room to spare IMO.
> 
> Not to mention it's not just a proposal, but in print in TDPL .
> 
> (dons flame war proof suit)
[...]

I don't see what's there to flamewar about. AFAIK @property enforcement
is going to happen sooner or later.


T

-- 
There is no gravity. The earth sucks.

Re: Arbitrary abbreviations in phobos considered ridiculous

[David Nadlinger]

On Friday, 9 March 2012 at 23:39:25 UTC, Steven Schveighoffer 
wrote:
I want to stress again the difference between C++'s namespaces, 
and D's module import mechanism.  In C++, you *deliberately* 
pull a namespace into your scope (and usually only in the 
implementation file, which doesn't affect any other 
implementation files), whereas in D, a standard "import 
std.datetime" *automatically* pulls its namespace into your 
scope, and any public imports it has made.


To be honest, I don't quite see the big difference here. Just as 
you can only #include a »namespaced« file without using a using 
directive, you can »static import« a module in D. You seem to 
be arguing that we shouldn't encourage use of these features (cf. 
the std.log discussion), but I can't quite follow you there.


Why would _not_ using static and selective imports be desirable? 
Don't we generally discourage people from write »using namespace 
std« in C++ or »import *« in Python as well? (I'm aware that 
the D module system is different, but the general idea is the 
same)


David

Re: Arbitrary abbreviations in phobos considered ridiculous

[Jonathan M Davis]

On Saturday, March 10, 2012 01:22:49 David Nadlinger wrote:
> On Saturday, 10 March 2012 at 00:16:14 UTC, Jonathan M Davis
> 
> wrote:
> > UFCS will give people more freedom and may help templates in
> > some cases, […]
> 
> Note aside: I think people tend to overestimate the amount of
> generic code that becomes easier to write/extend with UFCS, as D,
> in contrast to C++, doesn't have ADL.

That wouldn't surprise me at all. But then again, aside from using
arrays as ranges, I don't recall _ever_ running into a function in D where 
a user-defined type had a member function with that name, and a free
function had that name, and I wanted to call that function in a template and 
therefore had to use static ifs to separate the two. So, personally, I don't 
think that it will help me _at all_. I can see there being a few cases where 
it would though. If C++ had it, then could have implemented begin and end 
differently and not have to try and get everyone to switch over to using the 
free function versions for C++11. And in the case of arrays, having that sort 
of syntax has been _very_ useful for ranges.

But I don't buy that that's really the case for other primitive types 
(certainly not frequently), and unless you don't control the user-defined type 
that you're trying to operate on, you'd just put the function on the type 
itself when dealing with a user-defined type.

So, it'll probably help _some_, but I think that there's a good chance that 
you're right and that it won't be as useful as some people are expecting. But 
for better or worse, it looks like we're getting it.

- Jonathan M Davis

Re: Breaking backwards compatiblity

[Steven Schveighoffer]

On Fri, 09 Mar 2012 19:12:34 -0500, Adam D. Ruppe  
 wrote:



On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:

This is why we need to have a VERY high bar for breaking changes.


Please remember this if someone proposes enforcing
@property by default.


Clears the bar with room to spare IMO.

Not to mention it's not just a proposal, but in print in TDPL .

(dons flame war proof suit)

-STeve

Re: Breaking backwards compatiblity

[Jonathan M Davis]

On Friday, March 09, 2012 16:15:13 H. S. Teoh wrote:
> On Sat, Mar 10, 2012 at 01:02:35AM +0100, Andrej Mitrovic wrote:
> > Linus would probably hate D just as much as he hates C++. :p
> 
> Yeah... I can just imagine his eye scanning the description of D and
> stopping right at the word "GC", and immediately writing a flaming
> vitriolic post to LKML about how a GC is the absolutely worst thing one
> could possibly conceive of putting inside a kernel, and that any kernel
> developer caught flirting with the idea of using D ought to have all
> kernel patches ignored from that point on.

He hates function overloading! I question that he'd ever be happy with 
anything other than C. And he's so specialized in what he works on that I 
think that a number of his opinions are completely inapplicable to the 
majority of programmers. Some of what he says is very valuable, but he's a 
very opinionated person whose opinions often don't line up with the rest of 
the programming world. If you'll notice, Walter sometimes has similar issues 
simply due to the kind of stuff he works on (e.g. thinking that the fact that 
you could run your program in a debugger to see a segfault was enough (rather 
than getting some sort of stacktrace with a segfault), which works great for 
compilers, but works horribly for programs that run for weeks at a time). We 
all have our biases based on what we've worked on. Linus just so happens to be 
very famous and _very_ specialized in the type of stuff that he works on.

- Jonathan M Davis

Re: Breaking backwards compatiblity

[Jonathan M Davis]

On Saturday, March 10, 2012 01:12:34 Adam D. Ruppe wrote:
> On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
> > This is why we need to have a VERY high bar for breaking
> > changes.
> 
> Please remember this if someone proposes enforcing
> @property by default.
> 
> The -property switch is a big mistake that breaks a
> lot of code.

As I understand it, it's like override, it's being phased in, and it _will_ 
become the normal behavior.

There are also a number of things in the language that are supposed to be 
deprecated but have been sitting around for ages without actually being 
deprecated (e.g. delete).

Walter's sentiments may be good, but there are a number of things which are 
still in a transitional phase and _will_ end up breaking code. Of course, I'd
argue that stuff like deprecating/removing delete and fully enabling override
and @property _do_ pass the very high bar.

I think that his biggest complaint is minor changes (such as changing function
names) rather than the large changes that are still being made.

- Jonathan M Davis

Re: Arbitrary abbreviations in phobos considered ridiculous

[David Nadlinger]

On Saturday, 10 March 2012 at 00:16:14 UTC, Jonathan M Davis 
wrote:

UFCS will give people more freedom and may help templates in
some cases, […]


Note aside: I think people tend to overestimate the amount of 
generic code that becomes easier to write/extend with UFCS, as D, 
in contrast to C++, doesn't have ADL.


David

Re: Annotations or custom attributes

[Steven Schveighoffer]

On Fri, 09 Mar 2012 19:05:00 -0500, Ary Manzana   
wrote:



What are you talking about?


Who are you talking to?

:)

Seriously, though, I think Andrej sometimes quotes *nothing* (no offense  
for picking on you Andrej), and couple that with the newsgroup's seemingly  
random decision to start a new thread, or put a reply at the same level, I  
sometimes have no idea what he's talking about :)


-Steve

Re: Arbitrary abbreviations in phobos considered ridiculous

[Jonathan M Davis]

On Friday, March 09, 2012 18:50:50 bearophile wrote:
> Jonathan M Davis:
> > I don't know what the current state of UFCS is.
> 
> I have found a possible problem in it, and probably there are some missing
> parts, but it's working well.
> 
> At first I didn't like it a lot because it's cheap syntax sugar that adds no
> new power and gives programmers more freedom to write different-looking
> versions of the the same code (and this is often bad).

Which is one of the reasons that I really don't like the idea. Sometimes it's 
nice with strings, but it creates inconsistencies, and stuff like 5.max(7) just 
seems insane. UFCS will give people more freedom and may help templates in 
some cases, but I think that it's a major step back for readibility in 
general.

> But I have soon
> found that it's able to make functional-style code more readable, because
> you write: x.foo().bar().baz().spam()
> 
> Instead of this, where my eye sometimes loses count of the nesting level:
> spam(baz(bar(foo(x

I must be in the minority in that I find chaining with UFCS to be _harder_ to 
read than the more traditional way. It just feels insanely backwards to me. 
But some people definitely seem to prefer the UFCS chaining. YMMV.

- Jonathan M Davis

Re: Multiple return values...

[Timon Gehr]

On 03/10/2012 01:00 AM, Manu wrote:

On 10 March 2012 01:17, Timon Gehr mailto:timon.g...@gmx.ch>> wrote:

On 03/10/2012 12:02 AM, Manfred Nowak wrote:

Manu wrote:

I'm just talking about the ABI for returning multiple
values, not
chaining


Does this mean, that you want a special type of "function"? For
example
this would be disallowed statement: `auto result= f( g(
parameters));',
if `f' and `g' are functions returning multiple values?


This needs to work. Multiple return values should integrate with the
existing language support for tuples.


What should that do exactly? A function that returns multiple values is
passed as an argument to another function... what exactly is fed to
which arguments of the outer function?


It would work like built-in tuples already do.

(int, int) foo(int a, int b){return (a,b);}

assert(foo(foo(foo(foo(1,2==(1,2));

(int, int) goo(int a, int b, int c){return (a+b, c);}

assert(goo(foo(2,3),1) == (5,1));



Describe how you see multiple return values working through tuples,
while satisfying the issues I raise in my first couple of posts?


I have done so in my other post, you may refer to that one if something 
is still unclear: http://forum.dlang.org/post/jjdhdk$16v3$1...@digitalmars.com

Re: Breaking backwards compatiblity

[David Nadlinger]

On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
This is why we need to have a VERY high bar for breaking 
changes.


Oh, and how do you intend to accomplish that with things like bug 
314 still being open (and code relying on the buggy behavior), 
and not even the language being finalized (think: shared)?


David

Re: Breaking backwards compatiblity

[Adam D. Ruppe]

On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
This is why we need to have a VERY high bar for breaking 
changes.


Please remember this if someone proposes enforcing
@property by default.

The -property switch is a big mistake that breaks a
lot of code.

Re: Breaking backwards compatiblity

[Manfred Nowak]

Walter Bright wrote:

>  we need to have a VERY high bar for breaking changes.

To me a "breaking change" is a change in the documentation, i.e. change 
that narrows the validity of inputs, widens the validity of outputs, 
disables side effects which are enabled or enables side effects which 
are not mentioned before. Last but not least: all changes of the 
mapping from input to output are breaking changes too.

Although you yourself have stated, that the docs have precedence, I do 
believe, that the documentation was never in total sync with the 
behaviour of dmd.

Therefor without further description of "VERY high bar", demanding such   
seems to be pointless.

-manfred

Re: Breaking backwards compatiblity

[H. S. Teoh]

On Sat, Mar 10, 2012 at 01:02:35AM +0100, Andrej Mitrovic wrote:
> Linus would probably hate D just as much as he hates C++. :p

Yeah... I can just imagine his eye scanning the description of D and
stopping right at the word "GC", and immediately writing a flaming
vitriolic post to LKML about how a GC is the absolutely worst thing one
could possibly conceive of putting inside a kernel, and that any kernel
developer caught flirting with the idea of using D ought to have all
kernel patches ignored from that point on.

:-)


T

-- 
Amateurs built the Ark; professionals built the Titanic.

Re: Annotations or custom attributes

[Ary Manzana]

What are you talking about?

Re: Arbitrary abbreviations in phobos considered ridiculous

[H. S. Teoh]

On Fri, Mar 09, 2012 at 06:50:50PM -0500, bearophile wrote:
> Jonathan M Davis:
> 
> > I don't know what the current state of UFCS is.
> 
> I have found a possible problem in it, and probably there are some
> missing parts, but it's working well.

I found that x.foo doesn't work, it needs to be x.foo(). But we're
deprecating omission of parentheses of non-@property functions anyway,
and an external function can hardly be a @property of anything, so I
don't think this needs to be fixed.


> At first I didn't like it a lot because it's cheap syntax sugar that
> adds no new power and gives programmers more freedom to write
> different-looking versions of the the same code (and this is often
> bad).

But it also allows you to write pseudo-members for generic templates
that want to access built-in types via some abstract interface. This
makes template code much much cleaner.


> But I have soon found that it's able to make functional-style code
> more readable, because you write:
> x.foo().bar().baz().spam()
> 
> Instead of this, where my eye sometimes loses count of the nesting level:
> spam(baz(bar(foo(x
[...]

Personally, I find the chained syntax rather jarring if the object of
each . is different. I'm OK with things like jQuery where the base
object is always the same, but if it changes across the .'s, it can get
confusing to read.

OTOH, this is a refreshing change from centuries of silly backwards
function notation that we inherited from math, so maybe this is a good
thing after all. :-)


T

-- 
Always remember that you are unique. Just like everybody else. -- despair.com

Re: Breaking backwards compatiblity

[Andrej Mitrovic]

Linus would probably hate D just as much as he hates C++. :p

Re: Multiple return values...

[Manu]

On 10 March 2012 01:17, Timon Gehr  wrote:

> On 03/10/2012 12:02 AM, Manfred Nowak wrote:
>
>> Manu wrote:
>>
>>  I'm just talking about the ABI for returning multiple values, not
>>> chaining
>>>
>>
>> Does this mean, that you want a special type of "function"? For example
>> this would be disallowed statement: `auto result= f( g( parameters));',
>> if `f' and `g' are functions returning multiple values?
>>
>>
> This needs to work. Multiple return values should integrate with the
> existing language support for tuples.
>

What should that do exactly? A function that returns multiple values is
passed as an argument to another function... what exactly is fed to which
arguments of the outer function?
Describe how you see multiple return values working through tuples, while
satisfying the issues I raise in my first couple of posts?

Re: Multiple return values...

[Timon Gehr]

On 03/10/2012 12:27 AM, Andrei Alexandrescu wrote:

On 3/9/12 10:16 AM, Timon Gehr wrote:

There are two parts, syntax and semantics.

Semantics:
D is already able to express those:

template Tuple(T...){alias T Tuple;} // not the same as
std.typecons.Tuple!

// function with multiple return values:
Tuple!(int,double) foo(int a, double b){
Tuple!(int, double) result; // ok, _no imposed memory layout_
result[0] = a; // ok
result[1] = a+b; // ok
return result;
}

Multiple return values are currently *disallowed explicitly*:
DMD sez: "Error: functions cannot return a tuple"

Just specify the ABI, implement the code gen, and we're done.

Moot point: built-in tuples auto-flatten inside comma-separated lists.

std.typecons.Tuple is a hack to circumvent the arbitrary "cannot return
tuple from function" restriction as well as the auto-flattening.


No, it was more like an implementation of a generic tuple.



Yes, but we wouldn't have needed it if the built-in one would have been 
considered sufficient. It is akin to implementing an 'Int' struct in the 
standard library that wraps a built-in 'int' but does not implicitly 
convert to unsigned.



The
problem is that it is implemented as a struct with a built-in tuple
member. The fact that it is a struct imposes a memory layout. This is
just a side-effect of attempting to address the other two issues. It is
not something that is desirable.


Why?

I don't understand what you're trying to solve, that Tuple is not good at.


Andrei


Off the top of my head:

- Returning it from a function is not efficient.

- It does not play very nicely with type deduction.

- It has clumsy syntax and is therefore rarely used.

Notably, there is no convenient unpacking syntax. Walter does not merge 
the patches of Kenji Hara that would fix this because presumably he 
fears it could get in the way of a more general solution.


- It is a trivial wrapper for an underpowered built-in type. This causes 
confusion.



This situation is neither particularly pragmatic nor pure enough. I'd 
call it a wart.

Re: Arbitrary abbreviations in phobos considered ridiculous

[bearophile]

Jonathan M Davis:

> I don't know what the current state of UFCS is.

I have found a possible problem in it, and probably there are some missing 
parts, but it's working well.

At first I didn't like it a lot because it's cheap syntax sugar that adds no 
new power and gives programmers more freedom to write different-looking 
versions of the the same code (and this is often bad). But I have soon found 
that it's able to make functional-style code more readable, because you write:
x.foo().bar().baz().spam()

Instead of this, where my eye sometimes loses count of the nesting level:
spam(baz(bar(foo(x

Bye,
bearophile

UFCS (Was: Re: Arbitrary abbreviations in phobos considered ridiculous)

[H. S. Teoh]

On Fri, Mar 09, 2012 at 04:30:11PM -0700, Brad Anderson wrote:
> On Fri, Mar 9, 2012 at 4:24 PM, Jonathan M Davis wrote:
[...]
> > I don't know what the current state of UFCS is. I know that Kenji
> > has been working on it and that at least some portion of it has been
> > checked in, but what exactly it enables at this point, I don't know.
[...]
> Here are the unittests he added if you are curious about what
> currently works in dmd HEAD:
> https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/ufcs.d

Wow, 2.5.twice==5.0 works now? So does 2.5.sqrt()! And pseudo-members
for structs!  And classes!  Amazing!  Kudos to Kenji!


T

-- 
Question authority. Don't ask why, just do it.

Re: Breaking backwards compatiblity

[Steven Schveighoffer]

On Fri, 09 Mar 2012 18:14:39 -0500, H. S. Teoh   
wrote:



On Fri, Mar 09, 2012 at 11:46:24PM +0100, Alex Rønne Petersen wrote:

On 09-03-2012 23:32, Walter Bright wrote:
>This statement is from Linus Torvalds about breaking binary  
compatibility:

>
>https://lkml.org/lkml/2012/3/8/495
>
>While I don't think we need to worry so much at the moment about
>breaking binary compatibility with new D releases, we do have a big
>problem with breaking source code compatibility.
>
>This is why we need to have a VERY high bar for breaking changes.

If we want to start being able to avoid breaking changes, we
*really* need to finally deprecate the stuff that's been slated for
deprecation for ages...

[...]

Does that include std.stdio and std.stream? When are we expecting std.io
to be ready?


Sadly, I have no guarantees for when it will be ready.  The rewrite is  
mostly in place, what I'm struggling with is how to make it backwards  
compatible with std.stdio.  Specifically, I think I need to rewrite  
std.typecons.RefCounted to be more flexible.



IMHO, this is one major change that needs to happen sooner rather than
later. The current lack of interoperability between std.stdio and
std.stream is a big detraction from Phobos' overall quality.


I agree, as I watch other modules which would benefit from the rewrite get  
more attention, I cringe hoping that it doesn't introduce something that  
would necessitate a complete rewrite with the new system (thereby making  
my case for rewriting std.stdio weaker).


It's my number 1 priority for D.  The problem is that D is not my number 1  
priority right now :(


If you want to take a look so far (I haven't compiled in a long time since  
starting the migration to backwards compatibility):


https://github.com/schveiguy/phobos/blob/new-io2/std/io.d

I also have a trello card for it...

-Steve

Re: Arbitrary abbreviations in phobos considered ridiculous

[Brad Anderson]

On Fri, Mar 9, 2012 at 4:45 PM, Jonathan M Davis wrote:

> On Friday, March 09, 2012 18:39:25 Steven Schveighoffer wrote:
> > I want to stress again the difference between C++'s namespaces, and D's
> > module import mechanism. In C++, you *deliberately* pull a namespace into
> > your scope (and usually only in the implementation file, which doesn't
> > affect any other implementation files), whereas in D, a standard "import
> > std.datetime" *automatically* pulls its namespace into your scope, and
> any
> > public imports it has made.
>
> Yeah. D has great tools for getting around conflicts, but things tend to
> conflict by default, which means that it's very easy to break code by
> introducing conflicts when adding functions.
>
>
Hmm, fair enough.  In our case they were essentially pulled into the global
namespace due to some questionable decisions with regard to namespaces made
in our project.  The difference between D and C++ is important to point out
though so thanks for clarifying.

Regards,
Brad Anderson


> - Jonathan M Davis
>

Re: Arbitrary abbreviations in phobos considered ridiculous

[Jonathan M Davis]

On Friday, March 09, 2012 18:39:25 Steven Schveighoffer wrote:
> I want to stress again the difference between C++'s namespaces, and D's
> module import mechanism. In C++, you *deliberately* pull a namespace into
> your scope (and usually only in the implementation file, which doesn't
> affect any other implementation files), whereas in D, a standard "import
> std.datetime" *automatically* pulls its namespace into your scope, and any
> public imports it has made.

Yeah. D has great tools for getting around conflicts, but things tend to 
conflict by default, which means that it's very easy to break code by 
introducing conflicts when adding functions.

- Jonathan M Davis

Re: Annotations or custom attributes

[Steven Schveighoffer]

On Fri, 09 Mar 2012 18:23:17 -0500, Andrei Alexandrescu  
 wrote:



On 3/9/12 8:30 AM, Jacob Carlborg wrote:

As may serialization library Orange already does:
http://dl.dropbox.com/u/18386187/orange_docs/orange.serialization.Serializable.html


Look for "NonSerialized".


Saw that after posting. Cool!

Andrei

P.S. Please don't overquote, you systematically do so. Thanks!


Please continue to quote the previous two messages for context if you feel  
like it.  I enjoy not having to look back to previous messages.  Thanks!


-Steve

Re: Arbitrary abbreviations in phobos considered ridiculous

[Steven Schveighoffer]

On Fri, 09 Mar 2012 18:16:56 -0500, Brad Anderson  wrote:

On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis  
wrote:



On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote:
> I'll say I *don't* agree with the rejection of aliases on principle --
> aliases can be extremely useful/helpful, and they cost literally  
nothing

> (the "cognitive cost" on the docs is a BS argument IMO). I just don't
> agree with consuming so many common symbols for the sake of sugar.

aliases need to have a really good argument for existing. If UFCS is  
fully

implemented, then I think that there is _some_ argument for having stuff
like
hours and minutes, because then you can do stuff like 5.seconds()  
(though
honestly, I really don't like the idea). The alias enables different  
usages

rather than simply being another name for the same thing.

Now, in this particular case, it's that much worse for exactly the  
reason

that
you're against it: it uses common names for free functions. It's not as
big a
problem as it would be in C or C++, but it's still a problem. There's  
also

some risk that it will break code.


Oh, and I'd just like to add some of my experience to this. These names  
are

used by Boost's datetime library and they've never been a problem for me
and at work we make extensive use of Boost datetime.  There is risk but I
think in this specific case they are fairly small (especially in D, over
C++).


I want to stress again the difference between C++'s namespaces, and D's  
module import mechanism.  In C++, you *deliberately* pull a namespace into  
your scope (and usually only in the implementation file, which doesn't  
affect any other implementation files), whereas in D, a standard "import  
std.datetime" *automatically* pulls its namespace into your scope, and any  
public imports it has made.


I've used boost's datetime.  I didn't really like the whole "different  
types for each unit" mechanism, but I used it with success, and was glad I  
didn't have to re-invent it :)  But then again, I used it as the original  
date/time lib for my project.


-Steve

Re: Arbitrary abbreviations in phobos considered ridiculous

[Brad Anderson]

On Fri, Mar 9, 2012 at 4:24 PM, Jonathan M Davis wrote:

> On Friday, March 09, 2012 16:08:34 Brad Anderson wrote:
> > On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis  >wrote:
> > > On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote:
> > > > I'll say I *don't* agree with the rejection of aliases on principle
> --
> > > > aliases can be extremely useful/helpful, and they cost literally
> nothing
> > > > (the "cognitive cost" on the docs is a BS argument IMO). I just don't
> > > > agree with consuming so many common symbols for the sake of sugar.
> > >
> > > aliases need to have a really good argument for existing. If UFCS is
> fully
> > > implemented, then I think that there is _some_ argument for having
> stuff
> > > like
> > > hours and minutes, because then you can do stuff like 5.seconds()
> (though
> > > honestly, I really don't like the idea). The alias enables different
> > > usages
> > > rather than simply being another name for the same thing.
> >
> > What remains on UFCS? I've heard someone (Nick?) say he'd like it to
> match
> > static member functions too. I haven't tested but it seems like
> > 5.seconds() should work ever since Kenji's pull request was merged a
> couple
> > of days ago (thanks Kenji and Walter, I'm really looking forward to that
> > change).
>
> I don't know what the current state of UFCS is. I know that Kenji has been
> working on it and that at least some portion of it has been checked in, but
> what exactly it enables at this point, I don't know.
>
> - Jonathan M Davis
>

Here are the unittests he added if you are curious about what currently
works in dmd HEAD:
https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/ufcs.d

The issue "[tdpl] Implement uniform function call syntax" <
http://d.puremagic.com/issues/show_bug.cgi?id=3382> is marked as RESOLVED
FIXED so, as far as I know, UFCS is done (ignoring the inevitable bugs that
will eventually be uncovered).

Regards,
Brad Anderson

Re: Arbitrary abbreviations in phobos considered ridiculous

[Jonathan M Davis]

On Friday, March 09, 2012 16:16:56 Brad Anderson wrote:
> On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis wrote:
> > On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote:
> > > I'll say I *don't* agree with the rejection of aliases on principle --
> > > aliases can be extremely useful/helpful, and they cost literally nothing
> > > (the "cognitive cost" on the docs is a BS argument IMO). I just don't
> > > agree with consuming so many common symbols for the sake of sugar.
> > 
> > aliases need to have a really good argument for existing. If UFCS is fully
> > implemented, then I think that there is _some_ argument for having stuff
> > like
> > hours and minutes, because then you can do stuff like 5.seconds() (though
> > honestly, I really don't like the idea). The alias enables different
> > usages
> > rather than simply being another name for the same thing.
> > 
> > Now, in this particular case, it's that much worse for exactly the reason
> > that
> > you're against it: it uses common names for free functions. It's not as
> > big a
> > problem as it would be in C or C++, but it's still a problem. There's also
> > some risk that it will break code.
> 
> Oh, and I'd just like to add some of my experience to this. These names are
> used by Boost's datetime library and they've never been a problem for me
> and at work we make extensive use of Boost datetime. There is risk but I
> think in this specific case they are fairly small (especially in D, over
> C++). We switched to Boost datetime after we had hundreds of thousands of
> lines of code written using a different system and I didn't encounter any
> problems with the duration shortcut functions clashing.
> 
> Anyway, it sounds like Walter is probably opposed from what he was saying
> in the other thread so this conversation is probably moot.

I'd say that there's a higher chance of the aliases being added than of dur 
being changed to duration. Changing dur will _definitely_ break code and make 
using it worse for exactly the same reason that it's dur in the first place - 
it's too long when combined with the required units string. The aliases might 
break code, but it's probably only in cases where someone already has free 
functions with those names, and it's more likely that they'll have variables 
with those names, which are less likely to conflict.

So, while I don't really like the idea of adding the aliases, they _might_ be 
added, because they probably won't break anything, and they enable UFCS. But 
there's not a good enough reason to change dur to duration at this point.

- Jonathan M Davis

Re: Multiple return values...

[Andrei Alexandrescu]

On 3/9/12 10:16 AM, Timon Gehr wrote:

There are two parts, syntax and semantics.

Semantics:
D is already able to express those:

template Tuple(T...){alias T Tuple;} // not the same as std.typecons.Tuple!

// function with multiple return values:
Tuple!(int,double) foo(int a, double b){
Tuple!(int, double) result; // ok, _no imposed memory layout_
result[0] = a; // ok
result[1] = a+b; // ok
return result;
}

Multiple return values are currently *disallowed explicitly*:
DMD sez: "Error: functions cannot return a tuple"

Just specify the ABI, implement the code gen, and we're done.

Moot point: built-in tuples auto-flatten inside comma-separated lists.

std.typecons.Tuple is a hack to circumvent the arbitrary "cannot return
tuple from function" restriction as well as the auto-flattening.


No, it was more like an implementation of a generic tuple.


The
problem is that it is implemented as a struct with a built-in tuple
member. The fact that it is a struct imposes a memory layout. This is
just a side-effect of attempting to address the other two issues. It is
not something that is desirable.


Why?

I don't understand what you're trying to solve, that Tuple is not good at.


Andrei

Re: Annotations or custom attributes

[Andrei Alexandrescu]

On 3/9/12 8:30 AM, Jacob Carlborg wrote:

As may serialization library Orange already does:
http://dl.dropbox.com/u/18386187/orange_docs/orange.serialization.Serializable.html


Look for "NonSerialized".


Saw that after posting. Cool!

Andrei

P.S. Please don't overquote, you systematically do so. Thanks!

Re: Breaking backwards compatiblity

[Jonathan M Davis]

On Friday, March 09, 2012 15:14:39 H. S. Teoh wrote:
> On Fri, Mar 09, 2012 at 11:46:24PM +0100, Alex Rønne Petersen wrote:
> > On 09-03-2012 23:32, Walter Bright wrote:
> > >This statement is from Linus Torvalds about breaking binary
> > >compatibility:
> > >
> > >https://lkml.org/lkml/2012/3/8/495
> > >
> > >While I don't think we need to worry so much at the moment about
> > >breaking binary compatibility with new D releases, we do have a big
> > >problem with breaking source code compatibility.
> > >
> > >This is why we need to have a VERY high bar for breaking changes.
> > 
> > If we want to start being able to avoid breaking changes, we
> > *really* need to finally deprecate the stuff that's been slated for
> > deprecation for ages...
> 
> [...]
> 
> Does that include std.stdio and std.stream? When are we expecting std.io
> to be ready?
> 
> IMHO, this is one major change that needs to happen sooner rather than
> later. The current lack of interoperability between std.stdio and
> std.stream is a big detraction from Phobos' overall quality.

Note that he didn't say that we should _never_ make breaking changes but 
rather that we need to have a very high bar for making such changes. In 
particular, it's stuff like renaming functions without changing functionality 
that he's against.

If a module really needs a rewrite, then it'll get a rewrite, but we also need 
to do our best to avoid the need. And in the long run, it will hopefully be 
incredibly rare that we'll consider replacing modules. But there _are_ a few 
modules which are going to be replaced or rewritten. It's just that those are 
the modules that really need it and therefore meet the high bar required to 
make such changes.

- Jonathan M Davis