Re: @property needed or not needed?

[thedeemon]

On Monday, 19 November 2012 at 21:44:35 UTC, Jonathan M Davis 
wrote:
Excep that i don't think that it's really a question of style. 
It's treating a
function as if it were a variable, when it's not only not a 
variable, but it's
not even acting like one. It's implying that the code has one 
set of semantics when it has another.


This is just an old habit to see identifier with parens as a 
function call and identifier without parens as a variable, so 
calling functions without parens seem too unconventional to you. 
However there are many languages which dropped this tradition and 
they are known for being expressive and concise, that's why 
people love them. Recently we saw an article from Walter about 
component programming which one could say was really about 
function composition. It's really convenient to write code in 
conveyor-style, this is what we see often in functional 
languages, as well as some dynamic OO ones. For example, the task 
of reversing words in a string may look like:


"one two three".split.map{|s| s.reverse}.join(' ')
in Ruby

print . unwords . map reverse . words $ "one two three"
in Haskell

"one two three" |> split " " |> List.map reverse |> String.join " 
" |> print_string

in OCaml
and something similar and even without dots in Scala.
Ease of chaining functions together is one of the things that 
make those languages so pleasant to work with. I love to have the 
same in current D and it would be a pity to lose it due to a 
clash with some old-fashioned tradition.

Re: Is there interest in a std.http?

[Jacob Carlborg]

On 2012-11-19 21:38, Tyler Jameson Little wrote:


I think the following are necessary:

* Access to underlying TcpSocket (for protocol upgrades, like WebSocket)
* HTTP body is a stream
* Simple HTTP requests
* Errors can be recovered from (allow user-defined error handlers):
* User settable size limits
   * Size of request line (1024 bytes by default)
   * Size of each header (1024 bytes by default)
   * Total size of header block (4096 bytes by default)


* HTTPS

--
/Jacob Carlborg

Re: half datatype?

[Jacob Carlborg]

On 2012-11-20 01:45, Manu wrote:

On 19 November 2012 22:28, Rob T mailto:r...@ucora.com>>
wrote:

On Monday, 19 November 2012 at 19:14:43 UTC, Jonathan M Davis wrote:

I'd never even _heard_ of half types before this discussion came
up. But then
again, the same goes for SIMD. And IIRC, there was some sort of
function
attribute relating to pointers and registers that you or some
other gaming
person was insisting on a while back, and I'd never heard of it
existing in
C++ either (as an extension or otherwise). You clearly program
in a very
different world than I do. I care about high performance in what
I do but
nothing on _that_ level. I suspect that this is another one of
those things
that certain folks would really like to have, and most of the
rest of us don't
have any real interest in and often know nothing about in the
first place. I
don't know that I really care whether it's added to the language
though. I'll
leave that sort of decision up to Walter.

If anything, I just find it interesting how many low level
things folks like
you keep coming up with as must-haves or very strong wants that
I've never
even heard of and will almost certainly never care about aside
perhaps from
how having them in D might help D catch on.

- Jonathan M Davis


Anyone interested in the low precision float types, and what they
are good for, can start here
http://www.opengl.org/wiki/__Small_Float_Formats


I did not read through all of this thread, but my guess is that the
people making the request for half float are mostly into game
development and image processing.

When I first started investigating D as a potential C++ replacement,
I noted that a lot of the "visible" development (what I could see
being publicized) was game development, so it seemed that for some
reason a lot of the D users were also game developers, so there's
perhaps something about D that they find attractive.


I've said it before, but I think D has MASSIVE potential in gaming. We
are an industry crying our for salvation from C++, but there's no
possibility to compromise on the level of access it provides us to the
hardware we work with.
D is the only language I know of that seriously threatens to offer
modern programming constructs, while still providing a syntax and
compiler technology that I can easily understand in terms of code
generation and can hit the metal when I need to.

Additionally, most games programmers have very long-term relationships
with C++ almost exclusively, so despite hating it, moving to something
utterly different like rust or whatever cool thing comes along will just
never fly. You'll never convince a team of 10-30 programmers to agree on
such a change all at once, and re-training staff in something so foreign
would never be economical.
D is again particularly interesting here because it's enough like C++
and C# that programmers feel immediately comfortable and somewhat
liberated, but not threatened. Also, in a lot of cases, the changes to D
are relatively intuitive. The things you expect should work, often just
do... but there are still lots of rough edges too.

Gaming is a very demanding and progressive field of software, but also
very backwards at the same time. It's a sort of unity between many
disciplines, and it all comes together under a performance critical and
usually embedded umbrella, in a highly competitive and fickle industry.
You can't tell the customer to upgrade their hardware when it needs to
run on a console with an ~8 year lifecycle. As a (tech/engine)
programmer, if you don't scrutinise the code generation, calling
conventions, memory access patterns, data layout and sizes, the
competition will, and their product will appear superior. Towards the
end of that 8 year cycle, programmers are REALLY squeezing these
machines. If the language doesn't support that, then you can't compete
anymore, hence we remain stuck on C++ (and there are many instances
where the industry is reverting to C because C++ is a bloaty pig).

Why game devs are interested so much in D is interesting considering
the GC is noted to be a problem for game devs. The work of H. S.
Teoh comes to mind with his work on a game engine, that pushed the
limits of the GC and std lib.


I'll admit this is my biggest fear hands down!
That said, D is the only GC based language I know if where the GC is
relatively optional. This allows us to hedge our bets, and ease in to it
slowly as we gain confidence and understanding of how it behaves.
I don't yet have much confidence in the GC, and generally avoid using
it. I only use it for short term allocations, or non-critical-loop work
which often only survive for the 

Re: The annoying D build system

[Jacob Carlborg]

On 2012-11-19 21:00, Andrei Alexandrescu wrote:


That's the name of the github project.


Yeah, but I haven't seen any other project that is actually dependent on 
the name of its own folder.



So if you have ideas on how to improve the above - great! Just don't
fall for Chesterton's fence fallacy.


One solution that instantly pops in my mind is using git submodules. 
Create a new repository, say "dlang", add the other repositories as git 
submoduels to "dlang". Then the build system can do whatever it wants in 
the "dlang" directory and its sub directories, but it shouldn't escape 
the "dlang" directory.


Since Make is one of the worst thing I know, I'm not very enthusiastic 
about improving the build system.


--
/Jacob Carlborg

Re: The annoying D build system

[Jacob Carlborg]

On 2012-11-19 11:34, Andrej Mitrovic wrote:


Well on win32 I have two directories on my drive, "dmd" and "dmd-git".
"dmd" is an official release, while "dmd-git" is git-head. The dir
structure is:

dmd-git\dmd2\src\dmd  <- git-head
dmd-git\dmd2\src\druntime <- git-head
dmd-git\dmd2\src\phobos <- git-head
dmd-git\dmd2\windows\  ... <- binaries, etc

"dmd-git" is in the PATH env variable before "dmd" so it always
overrides it. When I want to switch between using git-head and an
official release I append an underscore to "dmd-git" (a shortcut key
can do the trick using autohotkey).

It's the simplest system I could think of..


I think you misunderstood what I was trying to say, or I am 
misunderstanding you.


--
/Jacob Carlborg

Re: split dmd frontend into separate project

[Jacob Carlborg]

On 2012-11-19 15:46, Iain Buclaw wrote:


Yes it would make sense - no it can't be done because gdc/ldc makes
changes to their own copies of dfe.  The solution would be to fix dfe
so that multiple backends can use it.  But that it not currently the
case.


Wouldn't those changes be easier to make and maintain if the front end 
was a separate project, even if it can't be used unmodified.


--
/Jacob Carlborg

Re: About Boost.SIMD

[thedeemon]

On Monday, 19 November 2012 at 23:58:56 UTC, bearophile wrote:
Slides from last year, "Practical SIMD acceleration with 
Boost.SIMD", in C++, maybe they are useful for the D SIMD parts:


https://github.com/boostcon/2011_presentations/raw/master/thu/simd.pdf

I hope to see better in D.

Bye,
bearophile


BTW, what is the current state of SIMD in DMD? In 2.060 core.simd 
module is not even mentioned in Library Reference. It's present 
in the install, has some type definitions like int4 or double2 
but it's unclear if those types actually use SIMD instructions 
and for what operations.

Re: @property needed or not needed?

[deadalnix]

Le 19/11/2012 21:55, Andrei Alexandrescu a écrit :

On 11/20/12 12:28 AM, deadalnix wrote:

Le 18/11/2012 22:52, Andrei Alexandrescu a écrit :

On 11/19/12 1:02 AM, Rob T wrote:

So what's up with @property?


It's a mistake on top of another. We need to redesign it to such that
the keyword '@property' is only required in cases that otherwise would
be ambiguous (functions returning functions).

Andrei



It isn't the only ambiguous case.


That's why it's good to enumerate them all in
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP21.

Thanks,

Andrei


I'm not sure how it fit in the DIP but &funName is ambiguous when 
funName return a reference.


In general, mixes of returning callables or references, @properties, 
auto calling functions and &syntax does a really bad mix.

Re: @property needed or not needed?

[deadalnix]

Le 19/11/2012 21:53, Andrei Alexandrescu a écrit :

On 11/20/12 12:24 AM, deadalnix wrote:

Le 19/11/2012 06:58, Andrei Alexandrescu a écrit :

On 11/19/12 4:01 AM, monarch_dodra wrote:

I kind of agree with Jonathan here. @property really shines when you
want to "add" an attribute to a struct.


I kind of agree with him, too, but it would be a mistake to not reckon a
change in dynamics. UFCS makes all those extra parens just awkward, and
people will vote with their code regardless whether some particular
viewpoint from some particular angle considers the approach backwards.

Andrei


As aid bunch of time, I'm pretty sure we can have a clean semantic and
still allow mosts use of parenthsesless call using opDispatch .


Could you please give more detail? On first sight this seems to
complicate the majority case for the benefit of a few.

Andrei


consider the following opDispatch :

auto opDispatch(string name, T, U...)(T function() t, U args) {
return mixin("t()." ~ name ~ "(args)");
}

I ommited to support delegates and to do the right checks in order to 
make the example obvious.


With such opDispatch, it is easy to get an autoevaluation for chained 
functions call via UFCS. () is only required on the last one.


I don't see how it can complicate the current situation. The current 
situation is like crazy complicated, and nobody is sure of what can be 
expected to be the correct behavior in many corner cases.

Re: @property needed or not needed?

[Andrei Alexandrescu]

On 11/20/12 12:28 AM, deadalnix wrote:

Le 18/11/2012 22:52, Andrei Alexandrescu a écrit :

On 11/19/12 1:02 AM, Rob T wrote:

So what's up with @property?


It's a mistake on top of another. We need to redesign it to such that
the keyword '@property' is only required in cases that otherwise would
be ambiguous (functions returning functions).

Andrei



It isn't the only ambiguous case.


That's why it's good to enumerate them all in 
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP21.


Thanks,

Andrei

Re: @property needed or not needed?

[Andrei Alexandrescu]

On 11/20/12 12:24 AM, deadalnix wrote:

Le 19/11/2012 06:58, Andrei Alexandrescu a écrit :

On 11/19/12 4:01 AM, monarch_dodra wrote:

I kind of agree with Jonathan here. @property really shines when you
want to "add" an attribute to a struct.


I kind of agree with him, too, but it would be a mistake to not reckon a
change in dynamics. UFCS makes all those extra parens just awkward, and
people will vote with their code regardless whether some particular
viewpoint from some particular angle considers the approach backwards.

Andrei


As aid bunch of time, I'm pretty sure we can have a clean semantic and
still allow mosts use of parenthsesless call using opDispatch .


Could you please give more detail? On first sight this seems to 
complicate the majority case for the benefit of a few.


Andrei

Re: @property needed or not needed?

[Jonathan M Davis]

On Monday, November 19, 2012 21:31:09 deadalnix wrote:
> Le 19/11/2012 10:02, Adam D. Ruppe a écrit :
> > On Monday, 19 November 2012 at 15:01:36 UTC, Andrei Alexandrescu wrote:
> >> Would you please start a DIP with a paste of this idea?
> > 
> > here it is:
> > http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP21
> > 
> > I tried to implement this a while ago and hit some pain after some early
> > success. The pain was trying to get assignments to work without breaking
> > other cases like returning ref.
> > 
> > My plan was to make any reference to a @property change to a CallExp or
> > whatever. But if you do that and it is on the left hand side of an
> > assignment, you do the wrong thing.
> > 
> > foo = foo + 1;
> > 
> > should generally become:
> > 
> > foo(foo() + 1);
> > 
> > but if there isn't a setter, we should leave it as foo() = foo() + 1;
> > and finding the setter is a bit of a pain. Then, of course, we ideally
> > want foo += 1 to work too..
> 
> This make it impossible to only define a getter only when one want to
> return by reference.

Returning by reference generally already defeats the purpose of defining a 
property function in the first place. Certainly, if you return by ref, it 
_definitely_ defeats the purpose of only defining a getter. By returning by ref 
from a getter, you've not only implicitly declared a setter, but you've made 
it impossible to verify anything about what's being set, because it's going 
through the ref rather than through an actual setter.

- Jonathan M Davis

Re: @property needed or not needed?

[deadalnix]

Le 19/11/2012 10:02, Adam D. Ruppe a écrit :

On Monday, 19 November 2012 at 15:01:36 UTC, Andrei Alexandrescu wrote:

Would you please start a DIP with a paste of this idea?


here it is:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP21

I tried to implement this a while ago and hit some pain after some early
success. The pain was trying to get assignments to work without breaking
other cases like returning ref.

My plan was to make any reference to a @property change to a CallExp or
whatever. But if you do that and it is on the left hand side of an
assignment, you do the wrong thing.

foo = foo + 1;

should generally become:

foo(foo() + 1);

but if there isn't a setter, we should leave it as foo() = foo() + 1;
and finding the setter is a bit of a pain. Then, of course, we ideally
want foo += 1 to work too..



This make it impossible to only define a getter only when one want to 
return by reference.



Maybe someone who knows the compiler better than me will make it look
easy though.

Re: @property needed or not needed?

[deadalnix]

Le 18/11/2012 22:52, Andrei Alexandrescu a écrit :

On 11/19/12 1:02 AM, Rob T wrote:

So what's up with @property?


It's a mistake on top of another. We need to redesign it to such that
the keyword '@property' is only required in cases that otherwise would
be ambiguous (functions returning functions).

Andrei



It isn't the only ambiguous case.

Re: @property needed or not needed?

[deadalnix]

Le 19/11/2012 06:58, Andrei Alexandrescu a écrit :

On 11/19/12 4:01 AM, monarch_dodra wrote:

I kind of agree with Jonathan here. @property really shines when you
want to "add" an attribute to a struct.


I kind of agree with him, too, but it would be a mistake to not reckon a
change in dynamics. UFCS makes all those extra parens just awkward, and
people will vote with their code regardless whether some particular
viewpoint from some particular angle considers the approach backwards.

Andrei


As aid bunch of time, I'm pretty sure we can have a clean semantic and 
still allow mosts use of parenthsesless call using opDispatch .

Re: @property needed or not needed?

[deadalnix]

Le 19/11/2012 00:45, thedeemon a écrit :

On Monday, 19 November 2012 at 08:23:43 UTC, Jonathan M Davis wrote:

On Monday, November 19, 2012 09:16:29 Rob T wrote:

My guess is that if @property gets enforced, we'll see a lot of
functions with empty parameter lists being defined as @property
for the sole reason to get rid of having to type in the ().


Which completely violates the concept of a property in the first
place. It's
intended to be an abstraction for a variable. Using @property just to
get rid
of parens would be like naming types with verbs instead of nouns. It's
completely backwards.

- Jonathan M Davis


I very much like the combination of UFCS, ranges and parens-free style
which allows writing code like

iota(0, 100).map!(to!string).retro.take(50).retro[10].writeln;

So I like Andrei's idea to force @property only for those functions
where it's absolutely necessary to fight ambiguity.


With opDispatch and clear semantic, the following is doable :

iota(0, 100).map!(to!string).retro.take(50).retro[10].writeln();

No need for an ambiguous situation where function get called implicitly.

Re: Is there interest in a std.http?

[Andrei Alexandrescu]

On 11/19/12 11:26 PM, Andrei Alexandrescu wrote:

On 11/19/12 3:38 PM, Tyler Jameson Little wrote:

I'd like to see an HTTP module in Phobos, but I wanted to gauge interest
first and see if this has been discussed before.


I can say the following. We sorely need a server expert on board with
the time and inclination to write a good server-side networking
framework.


To clarify (lest this would be interpreted as excluding vibe.d from the 
category of good server-side networking frameworks): ... for inclusion 
in the standard library.


Andrei

Re: Bret Victor - Inventing on Principle

[Andrei Alexandrescu]

On 11/19/12 7:50 PM, Walter Bright wrote:

On 11/19/2012 6:26 AM, Regan Heath wrote:

Hope no-one minds..

I stumbled across this video which I thought was pretty darn cool:
http://www.youtube.com/watch?v=PUv66718DII


Can you give us a summary or synopsis?


"Worth watching."


Andrei

Re: Is there interest in a std.http?

[Andrei Alexandrescu]

On 11/19/12 3:38 PM, Tyler Jameson Little wrote:

I'd like to see an HTTP module in Phobos, but I wanted to gauge interest
first and see if this has been discussed before.


I can say the following. We sorely need a server expert on board with 
the time and inclination to write a good server-side networking 
framework. We have a couple, but for various reasons I have been unable 
to convince them (through newsgroup and private exchanges) to invest 
time in such an endeavor. That's mostly because lack of time - speaking 
for myself, I wish I found the time to learn about all that, which as 
far as I understand gravitates around notions such as asynchronous I/O, 
libevent/libevt, select(), and the such. I've never used them so I'd 
need to start from scratch.


We really need an expert. Look at the Go programming language - it's not 
remarkable, but it benefits of full-time dedication of experts in 
server-side programming, so it has acquired excellent library support 
for networking servers. And they milk that for all it's worth: any 
discussion, article, or blog post about Go gravitates toward the 
five-lines HTTP server with the same implacable reach as conversations 
with ideologists, which inevitably converge towards their ideological 
stronghold.



Andrei

Re: @property needed or not needed?

[Andrei Alexandrescu]

On 11/19/12 5:23 PM, Rob T wrote:

I don't have an answer, but there may be more to the picture than we think.


I agree. In particular I find it a specious argument to insist on 
religiously associating "()" with function calling and the lack thereof 
with variable access. I don't see myself, when seeing an expression like 
"generator(x, y, z).map!(x => x * x)()", going like "holy cow, good I 
saw those trailing parens, otherwise I would've sworn it was a 
variable". Trailing parens in UFCS chains are just warts, this is the 
reality. Let's deal with it.



Andrei

Re: Is there interest in a std.http?

[Tyler Jameson Little]

* HTTP body is a stream


No Content-Size, no multiple requests per connection (unless 
you use chunked encoding?).


Not sure what you mean. I meant incoming stream. There would be a 
request object with access to all other headers, it just wouldn't 
be read in until the user actually wanted it.



* User settable size limits
 * Size of request line (1024 bytes by default)
 * Size of each header (1024 bytes by default)
 * Total size of header block (4096 bytes by default)


I think this is pointless. Use an appender and the RFC limits. 
Unless you are serving VERY simple pages, the cost of a few 
allocations for handling the HTTP protocol's overhead will not 
be noticeable compared to the application's. (Slowloris is 
something to keep in mind, though.)


I just made up those limits, but the point is I'd like the user 
to be able to tweak those. The default will work for most people 
though.


My HTTP library, which is used for this forum and several other 
"production" projects, is here: 
https://github.com/CyberShadow/ae
The main problem with getting it into Phobos is that it's tied 
to a lot of other related code, such as the asynchronous 
sockets module, the unmanaged memory wrapper type, etc.


Cool, I didn't know that this was served by D code. I'll take a 
look at it.



Also, what about vibe.d?


vibe.d does a lot of things, and it probably does those things 
very well. It seems well maintained, and generally a good 
project. I think that a lot of the things it does well could be 
brought into the standard library. As this thread pointed out, 
there are several HTTP parsers floating around out there. For 
some, vibe.d might not be a perfect fit for whatever reason, but 
everyone can benefit from a simple HTTP library.


Maybe it shouldn't be as high-level as Go's http library, but it 
should at least make writing a simple HTTP server trivial.


Would a minor refactor of vibe.d be acceptable? This is pretty 
much what I'm looking for:


https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/common.d
https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/server.d

Except that I'd remove some parts of it, like JSON parsing.

I think that vibe.d could benefit from moving some of the code 
there into Phobos. I guess it comes down to whether it makes 
sense to make a standard HTTP library.

Re: Time for std.reflection

[Malte Skarupke]

I like it. First a couple details:


class ClassInfo {
@property:
string name();
string baseName();
string parentName(); // if applicable, null otherwise
string[] interfaces();
bool isShared();
Protection protection();
DataMemberInfo[] data();
MethodInfo[] methods();
Object defaultConstructor();
...
}


Why do you not use recursion here? Why not
ClassInfo base();
ClassInfo parent();
and then you get baseName by calling base.name;


Then for an e.g. method declaration we'd have:

class MethodInfo {
@property:
string name();
bool isStatic(), isFinal(), isOverride();
Protection protection();
string[] parameterTypes();
string[] parameterNames();
}


Do you think there'll be any way to get the actual types of the 
arguments and the return type back from the struct? I think that 
without compiler magic or an uncomfortable amount of templates it 
probably won't be possible, but I might be wrong.



Now to my big complaint:

I really dislike making the runtime api accessible through a 
mixin. I'd much prefer making it a non-member template. Reasons 
are
a) I don't want to store the runtime information in my type. A 
vtable pointer should be enough to get that information. Maybe 
use it as an index into a global immutable associative array. For 
modules and non-class types the name can act as a unique 
identifier.
b) It'd make it possible to get runtime information on types that 
I get from libraries.

c) It would lead to less coupling.
d) It would discourage writing types that rely on runtime 
reflection, but it would not make it impossible.

Downloadable spec for D version 2

[Edward Diener]

Is there a downloadable spec for the D version 2 language, in either PDF 
or HTML format ?

Re: Bret Victor - Inventing on Principle

[bearophile]

Walter Bright:


http://www.youtube.com/watch?v=PUv66718DII


Can you give us a summary or synopsis?


It's not easy to summarize it. Many talks are little more than 
the slides they are based on, but this talk contains lot of 
graphics and animation, it's really a talk that you have to see 
if you want to appreciate its contents, because it's mostly about 
visual ideas.


It discusses about using visualization to help design code and 
program, and more. This talk is now famous, it was a start of a 
little "revolution". After that talk many developments have 
happened. Maybe even the future LightTable IDE was inspired a bit 
by it. I have seen Khan and his academy software follow some of 
the ideas contained in that talk to teach JavaScript, and then I 
have seen another talk explain similar ideas better, and then 
other people criticize it a lot.


In the end part of me likes those ideas, and part of me doesn't 
like it. To teach things like StarLogo are in my opinion better 
for newbie programmers, but that talk is not just about new 
programmers. Some of those ideas are cool.


I have never linked this talk or the successive developments in 
this newsgroup because it being good stuff to know for every 
programmer, it's not much related to D and the not-interactive 
style of programming it asks for.


Bye,
bearophile

Re: half datatype?

[Rob T]

On Monday, 19 November 2012 at 20:28:22 UTC, Rob T wrote:
The work of H. S. Teoh comes to mind with his work on a game 
engine, that pushed the limits of the GC and std lib.


Not to undermine the work Teoh has done on D, but I meant 
Benjamin Thaut is the person who published his findings related 
to problems encountered with the GC and the std lib.


--rt

Re: half datatype?

[Manu]

On 20 November 2012 02:51, Jonathan M Davis  wrote:

> On Monday, November 19, 2012 12:55:11 Walter Bright wrote:
> > On 11/19/2012 12:28 PM, Rob T wrote:
> > > In any case, the point is that I don't think the D community should
> > > overlook what the game devs are doing, they're pushing D to its limits
> > > and are making D more visible than perhaps anyone.
> >
> > I agree.
> >
> > I might also point out that adoption of a language (or any new
> technology)
> > often happens because it solves a problem for an otherwise overlooked
> > niche, and their adoption of it drives it into the mainstream.
>
> I don't disagree at all. I just find it interesting how many things that
> the
> game devs keep coming up with that they consider critical that most of the
> rest of us haven't ever even considered and frequently know absolutely
> nothing
> about.
>

Dunno what to tell you.
Gamedev is a strange union of 3-4-5 very distinct fields of programming,
each with their own set of requirements, and often just the interaction
between them is an interesting problem in its self.
Engine programming is the most critical though, with virtually no room for
compromise. D needs to be competitive in that space if it hopes to dislodge
C/C++, and it's not far off.

Re: Time for std.reflection

[Manu]

Huge interest!
I wouldn't want to see static data structures bloat/clutter the exe though
in cases where it's not ever used/queried.
The object factory is already a serious problem.


On 22 July 2012 00:44, Andrei Alexandrescu wrote:

> Walter and I discussed the idea below a long time (years) ago. Most likely
> it's also been discussed in this newsgroup a couple of times. Given the
> state of the compiler back then, back then it seemed like a super cool idea
> that's entirely realizable, it would just take time for the compiler to
> become as capable as needed. Nowadays we're in shape to tackle it.
>
> Here "it" is.
>
> Back when runtime reflection was being discussed, my response was "let's
> focus on compile-time reflection, and then we can do run-time reflection on
> demand as a library". Though this might sound sensible, I initially didn't
> have a design. Now here's what we can do.
>
> Currently we have information about symbols as __traits(...) intrinsics
> wrapped in nice but scattered ways. Now that CTFE is good enough to
> manipulate structs and arrays thereof, we have the possibility to finally
> approach things in a nicely unified, structured way.
>
> First, we need to prime std.reflection with a few abstractions that
> characterize entities in a D program.
>
> class ModuleInfo {
> @property:
> string name();
> ImportInfo[] imports();
> DataInfo[] data();
> FunctionInfo[] functions();
> ClassInfo[] classes();
> StructInfo[] structs(); // includes unions
> TemplateInfo[] templates();
> EnumInfo[] enums();
> bool hasStaticCtor(), hasStaticDtor(),
>   hasSharedCtor(), hasSharedDtor();
> }
>
> Probably there are a few more pieces of data, but you get the idea. Then
> for each of the entities mentioned above we have a similar definition. For
> example:
>
> enum Protection { isPublic, isPackage, isProtected, isPrivate }
>
> class ClassInfo {
> @property:
> string name();
> string baseName();
> string parentName(); // if applicable, null otherwise
> string[] interfaces();
> bool isShared();
> Protection protection();
> DataMemberInfo[] data();
> MethodInfo[] methods();
> Object defaultConstructor();
> ...
> }
>
> Then for an e.g. method declaration we'd have:
>
> class MethodInfo {
> @property:
> string name();
> bool isStatic(), isFinal(), isOverride();
> Protection protection();
> string[] parameterTypes();
> string[] parameterNames();
> }
>
> Some details may vary, e.g. some may be straight members instead of
> properties etc. (I used properties to allude to use of lazy gathering of
> information).
>
> So so far we have a nice collection of structured data associated with the
> entities in a D program. Note how this structuring differs yet has similar
> power to the primitives in std.traits; std.traits offers unstructured bits
> of information on demand (e.g. ParameterTypeNames) etc. but the objects
> above group information together per entity declared. All of the above goes
> in std.reflection, of course.
>
> ===
>
> On to primitives that return such data.
>
> Given that D can (since relatively recently) create and manipulate class
> objects during compilation too, it follows that the classes above can be
> accessed in two ways - through compile-time API and run-time API. When
> possible, the APIs may even use the same functions; some other times they
> will be necessarily different.
>
> There are two possible approaches to discovering such information. One is
> by fetching the ModuleInfo for the whole module and navigating it. Another
> one is by using search primitives from strings.
>
> So we should have e.g.
>
> // inside std.reflection
> ModuleInfo getModuleInfo(string moduleName);
>
> so a CT call would go like:
>
> // client code
> static info = getModuleInfo("std.algorithm")**;
>
> whereas a run-time call would be:
>
> // client code
> auto info = getModuleInfo("std.algorithm")**;
>
> In the latter case, the module needs to save all needed information for
> ri, so it should plant this:
>
> // inside std.algorithm
> mixin(**makeModuleInfoAvailableDynamic**ally());
>
> The mixin would generate all information needed and would store it for
> later dynamic use.
>
> A search API would go like e.g.
>
> ClassInfo getClassInfo(string className);
>
> In this case the class name could be qualified with module information etc.
>
> ===
>
> With this design we unify compile-time and run-time type manipulation in
> simple ways, by defining structured information about declarations that can
> be queried during compilation or dynamically.
>
> Please chime in with thoughts. Would someone want to pioneer this project?
>
>
> Andrei
>

Re: half datatype?

[Jonathan M Davis]

On Monday, November 19, 2012 12:55:11 Walter Bright wrote:
> On 11/19/2012 12:28 PM, Rob T wrote:
> > In any case, the point is that I don't think the D community should
> > overlook what the game devs are doing, they're pushing D to its limits
> > and are making D more visible than perhaps anyone.
> 
> I agree.
> 
> I might also point out that adoption of a language (or any new technology)
> often happens because it solves a problem for an otherwise overlooked
> niche, and their adoption of it drives it into the mainstream.

I don't disagree at all. I just find it interesting how many things that the 
game devs keep coming up with that they consider critical that most of the 
rest of us haven't ever even considered and frequently know absolutely nothing 
about.

- Jonathan M Davis

Re: Bret Victor - Inventing on Principle

[Walter Bright]

On 11/19/2012 6:26 AM, Regan Heath wrote:

Hope no-one minds..

I stumbled across this video which I thought was pretty darn cool:
http://www.youtube.com/watch?v=PUv66718DII


Can you give us a summary or synopsis?

Re: half datatype?

[Manu]

On 19 November 2012 22:28, Rob T  wrote:

> On Monday, 19 November 2012 at 19:14:43 UTC, Jonathan M Davis wrote:
>
>> I'd never even _heard_ of half types before this discussion came up. But
>> then
>> again, the same goes for SIMD. And IIRC, there was some sort of function
>> attribute relating to pointers and registers that you or some other gaming
>> person was insisting on a while back, and I'd never heard of it existing
>> in
>> C++ either (as an extension or otherwise). You clearly program in a very
>> different world than I do. I care about high performance in what I do but
>> nothing on _that_ level. I suspect that this is another one of those
>> things
>> that certain folks would really like to have, and most of the rest of us
>> don't
>> have any real interest in and often know nothing about in the first
>> place. I
>> don't know that I really care whether it's added to the language though.
>> I'll
>> leave that sort of decision up to Walter.
>>
>> If anything, I just find it interesting how many low level things folks
>> like
>> you keep coming up with as must-haves or very strong wants that I've never
>> even heard of and will almost certainly never care about aside perhaps
>> from
>> how having them in D might help D catch on.
>>
>> - Jonathan M Davis
>>
>
> Anyone interested in the low precision float types, and what they are good
> for, can start here
> http://www.opengl.org/wiki/**Small_Float_Formats
>
> I did not read through all of this thread, but my guess is that the people
> making the request for half float are mostly into game development and
> image processing.
>
> When I first started investigating D as a potential C++ replacement, I
> noted that a lot of the "visible" development (what I could see being
> publicized) was game development, so it seemed that for some reason a lot
> of the D users were also game developers, so there's perhaps something
> about D that they find attractive.
>

I've said it before, but I think D has MASSIVE potential in gaming. We are
an industry crying our for salvation from C++, but there's no possibility
to compromise on the level of access it provides us to the hardware we work
with.
D is the only language I know of that seriously threatens to offer modern
programming constructs, while still providing a syntax and compiler
technology that I can easily understand in terms of code generation and can
hit the metal when I need to.

Additionally, most games programmers have very long-term relationships with
C++ almost exclusively, so despite hating it, moving to something utterly
different like rust or whatever cool thing comes along will just never fly.
You'll never convince a team of 10-30 programmers to agree on such a change
all at once, and re-training staff in something so foreign would never be
economical.
D is again particularly interesting here because it's enough like C++ and
C# that programmers feel immediately comfortable and somewhat liberated,
but not threatened. Also, in a lot of cases, the changes to D are
relatively intuitive. The things you expect should work, often just do...
but there are still lots of rough edges too.

Gaming is a very demanding and progressive field of software, but also very
backwards at the same time. It's a sort of unity between many disciplines,
and it all comes together under a performance critical and usually embedded
umbrella, in a highly competitive and fickle industry.
You can't tell the customer to upgrade their hardware when it needs to run
on a console with an ~8 year lifecycle. As a (tech/engine) programmer, if
you don't scrutinise the code generation, calling conventions, memory
access patterns, data layout and sizes, the competition will, and their
product will appear superior. Towards the end of that 8 year cycle,
programmers are REALLY squeezing these machines. If the language doesn't
support that, then you can't compete anymore, hence we remain stuck on C++
(and there are many instances where the industry is reverting to C because
C++ is a bloaty pig).

Why game devs are interested so much in D is interesting considering the GC
> is noted to be a problem for game devs. The work of H. S. Teoh comes to
> mind with his work on a game engine, that pushed the limits of the GC and
> std lib.
>

I'll admit this is my biggest fear hands down!
That said, D is the only GC based language I know if where the GC is
relatively optional. This allows us to hedge our bets, and ease in to it
slowly as we gain confidence and understanding of how it behaves.
I don't yet have much confidence in the GC, and generally avoid using it. I
only use it for short term allocations, or non-critical-loop work which
often only survive for the scope of the function.

I don't have enough experience to make any reasonable claims about its
affect on performance, but I have seen a lot of benchmarks in this NG
though that have shown it is significantly inferior to C# and Java. That
doesn't

Re: Is there interest in a std.http?

[Adam D. Ruppe]

On Monday, 19 November 2012 at 23:57:35 UTC, Tyler Jameson Little 
wrote:
Awesome. I assume this hasn't gone through rigorous testing, 
but has it been used in production?


I've been using it for almost all my work apps for the last... I 
think three years now. None of them so far have huge userbases, 
but it has been in steady use for a while.


The others in this thread have pointed out the other options that 
have some users: Vladimir's library that runs the forum, and 
vibe.d that seems to be the most popular. I haven't used either 
of them though.



How do you feel about function pointer callbacks?


We could also do them as virtual functions... that's a little 
easier in the setup I have because the constructor arguments are 
messy, whereas subclassing is a lot simpler.


But yeah, it sounds like a decent plan.

Re: Is there interest in a std.http?

[Vladimir Panteleev]

On Monday, 19 November 2012 at 20:38:56 UTC, Tyler Jameson Little 
wrote:

* HTTP body is a stream


No Content-Size, no multiple requests per connection (unless you 
use chunked encoding?).



* User settable size limits
  * Size of request line (1024 bytes by default)
  * Size of each header (1024 bytes by default)
  * Total size of header block (4096 bytes by default)


I think this is pointless. Use an appender and the RFC limits. 
Unless you are serving VERY simple pages, the cost of a few 
allocations for handling the HTTP protocol's overhead will not be 
noticeable compared to the application's. (Slowloris is something 
to keep in mind, though.)


My HTTP library, which is used for this forum and several other 
"production" projects, is here: https://github.com/CyberShadow/ae
The main problem with getting it into Phobos is that it's tied to 
a lot of other related code, such as the asynchronous sockets 
module, the unmanaged memory wrapper type, etc.


Also, what about vibe.d?

Re: Is there interest in a std.http?

[Pragma Tix]

Before you spend too much time :
https://github.com/rejectedsoftware/vibe.d/tree/master/source/vibe/http



On Monday, 19 November 2012 at 20:38:56 UTC, Tyler Jameson Little 
wrote:
I'd like to see an HTTP module in Phobos, but I wanted to gauge 
interest first and see if this has been discussed before.


An example of how I would like to interface with it (for 
creating a server):


interface HTTPHandler {
void serveHTTP(Request, Response);
}

class CustomHandler : HTTPHandler {

void serveHTTP(Request req, Response res) {
}
}

auto handler = new CustomHandler(); // implements 
http.Handler

auto server = new HttpServer(handler);
server.listen("0.0.0.0", 80);

As long as serveHttp() is thread safe, the http server could be 
concurrent or evented (with libev or similar) and the custom 
handler code wouldn't have to change.


I'm willing to put in the lion's share of the work (I've 
already written a bunch of it), but I'd naturally like to get 
some community input so I don't go in a completely wrong 
direction. I'm thinking of emulating Go's http library 
(http://golang.org/pkg/net/http), but of course D style.


I think the following are necessary:

* Access to underlying TcpSocket (for protocol upgrades, like 
WebSocket)

* HTTP body is a stream
* Simple HTTP requests
* Errors can be recovered from (allow user-defined error 
handlers):

* User settable size limits
  * Size of request line (1024 bytes by default)
  * Size of each header (1024 bytes by default)
  * Total size of header block (4096 bytes by default)

So, basically I'm looking for two things:

1. Interest level: willing to writ code, willing to test, want 
to use

2. Suggestions for the API/behavior

About Boost.SIMD

[bearophile]

Slides from last year, "Practical SIMD acceleration with 
Boost.SIMD", in C++, maybe they are useful for the D SIMD parts:


https://github.com/boostcon/2011_presentations/raw/master/thu/simd.pdf

I hope to see better in D.

Bye,
bearophile

Re: Is there interest in a std.http?

[Tyler Jameson Little]

I've been asked to put my cgi.d in phobos before (which 
includes a http server as well as a cgi, fastcgi, and scgi 
implementation of its common interface), so there's probably 
some interest.


I haven't put mine in just because I'm not particularly 
motivated to go through the red tape.


The file is cgi.d in here:
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff


Awesome. I assume this hasn't gone through rigorous testing, but 
has it been used in production?


* Errors can be recovered from (allow user-defined error 
handlers):

* User settable size limits


eh, I'm partially there on these. There's some constructor args 
you can play with and some degree of exception catching but 
probably not fully what you have in mind.


I'm thinking of something a little more sophisticated than 
exceptions. Exceptions unwind the stack, so you can't just 
continue where you left off.


How do you feel about function pointer callbacks? The http parser 
in node.js (https://github.com/joyent/http-parser) takes a struct 
of function pointers to handle errors/events. When the parser 
encounters a recoverable error (max header length reached), the 
programmer could opt to ignore it and continue the parse. 
Unrecoverable errors could throw exceptions (like trying to parse 
garbage data).


If an error is recovered, it would just continue as if nothing 
happened.


Of course, implementing this would increase complexity in the 
parser, but I think it's justified. Thoughts?

Re: Multidimensional array operator overloading

[bearophile]

1) Is multidimensional slicing supported? I.e., does opSlice 
support notation like arr[1..2, 2..3]?


I expect this to be eventually added. It seems a purely additive 
change, and even natural.


---

Jonathan M Davis:


We could then do
releases even though something as massive as 64-bit Windows 
support was being
worked on, because that work would be on a separate branch. But 
it seems that
Walter has never worked that way before, and he's having a very 
hard time adjusting to it.


Walter is sometimes moving slowly, but unlike lot of other people 
he never stops moving forward. So I think similar branching will 
happen.


Bye,
bearophile

Re: @property needed or not needed?

[Rob T]

On Monday, 19 November 2012 at 21:44:35 UTC, Jonathan M Davis 
wrote:
Excep that i don't think that it's really a question of style. 
It's treating a
function as if it were a variable, when it's not only not a 
variable, but it's
not even acting like one. It's implying that the code has one 
set of semantics
when it has another. Dropping parens when specifically creating 
a function
which is intended to emulate a variable makes sense. But 
dropping parens just
because you feel like it then makes a function look like a 
variable when it's
not and not intended to even act like one. That violates the 
very difference
between function and variable on even a conceptual level. It 
would be one
thing to make a particular character or sequence of characters 
optional when

doing so doesn't make it look like it's something else entirely
 (e.g.
optional braces don't make anything look like anything else - 
they just drop
some characters, and they don't introduce any ambiguities in 
the process). But
it's quite another to make those characters optional when they 
make one

language construct look like another.

- Jonathan M Davis


I see what you are saying.

Consider this:

@property allows a function to behave as if it were a variable, 
so in that case we're effectively creating an alternate set of 
language constructs for at least some functions. The enforcement 
through @property however constrains it to only behave as if it 
were a variable and not a function, there's no ambiguity in this 
case, and it's clearly intentional, not a mistake.


Without @property, but allowing the programmer to decide if, 
when, and where, a function may emulate a variable, and when it 
will not, may confuse some people and may also confuse the 
compiler in some cases, but it does offer the programmer 
additional flexibility that may prove to be useful, although it 
may also prove to be a costly mistake, and if so it may be a 
matter of how good the programmer is.


All I know at this point is that because @property was not fully 
implemented as originally intended, I was able to experience the 
flexibility, and personally I found it to be OK for whatever 
reason, esp wrt UFCS.


I would still be happy to have @property perform constraints to 
enforce a function to emulate a variable or to resolve 
ambiguities, and certainly for any function no matter where it 
may be declared. I can definitely see the value in that and I 
can't see any reason for not supporting it.


Side Note: In some cases you may want a setter but no getter for 
write only variable emulation, or a setter but no getter for read 
only emulation.


What is not so clear, is if optional () should be allowed or not, 
but I do understand the argument that it makes the code look 
better in some cases which in that case is a question of style 
rather than anything to do with @property.


Also do not forget that we can not only drop the (), but also 
perform assignments to functions that take in one variable, but 
I'm not sure if the return must be void for that to work. It 
seems strange to allow arbitrarily dual function/variable 
constructs for functions, but being strange does not necessarily 
mean it is wrong.


I do wonder however, if there's something much more fundamental 
or generalized going on with this that can settle the question in 
clear terms? I fully understand the variable emulation argument, 
and it's seems to be sound, however imagine reversing the 
argument and suggesting that all (or some) variables should be 
enforced to emulate function calls with @function.


We've seen this being done in C++, where I can initialize a 
variable in multiple emulated ways:


// class constructor emulation
int x(42);

// function emulation
int y;
x = y(42);

// regular variable form
int x = 42;

I don't have an answer, but there may be more to the picture than 
we think.


--rt

Re: @property needed or not needed?

[Mehrdad]

On Monday, 19 November 2012 at 20:00:27 UTC, monarch_dodra wrote:
You could argue that since a property-function is meant to 
emulate an attribute, that calling one and doing nothing is 
*always* wrong, regardless of side effect.



That's EXACTLY what I'm saying.

foo.property;

is ALWAYS wrong semantically speaking, regardless of what it 
_could_ or _happens_ to do if it was/is defined.
So even if popFront() was a property, my point would be that it 
should not be a property in the first place.




It's like saying you should be able to add integers and function 
pointers just because they're both integers underneath.


Sure, the machine can do it, but we disallow it because it makes 
no sense.


Ditto here.

Re: Multidimensional array operator overloading

[Jonathan M Davis]

On Monday, November 19, 2012 22:55:50 monarch_dodra wrote:
> Off topic: What is the release cycle of D? Seems like I've been
> on 2.060 forever.

Whenever Walter feels like doing a release.

Previously, we were at something like every 2 or 3 months, but that's gotten 
longer over the last year or two (you can look at the changelog for the actual 
release dates), and this particular release is delayed big time due to the 
addition of 64-bit Windows support. Presumably, once Walter feels that that's 
ready enough for release, then we'll do a release, and further releases will 
be closer to the 2 to 3 month mark again. However, this _is_ a good example of 
why we should be using branches more ( the fiasco of custom attributes being 
recently added to master being another good example). We could then do 
releases even though something as massive as 64-bit Windows support was being 
worked on, because that work would be on a separate branch. But it seems that 
Walter has never worked that way before, and he's having a very hard time 
adjusting to it.

- Jonathan M Davis

Re: Multidimensional array operator overloading

[monarch_dodra]

On Monday, 19 November 2012 at 18:02:32 UTC, H. S. Teoh wrote:

2) Is opDollar supported for multidimensional arrays? I.e., 
when you
write arr[1..$, 2..$], the $ in each dimension can potentially 
be
different values (say you have a 2x3 array, so the first $ is 
2, and the

second $ is 3)?


What Mike said.

However, complete support for $ is new, and only available in 
2.061 alpha. In the current public 2.060, you may get a link 
error.


Off topic: What is the release cycle of D? Seems like I've been 
on 2.060 forever.

Re: half datatype?

[Iain Buclaw]

On 19 November 2012 17:57, Manu  wrote:
> On 19 November 2012 19:28, Iain Buclaw  wrote:
>>
>> On 19 November 2012 16:04, Manu  wrote:
>> > On 19 November 2012 06:19, Walter Bright 
>> > wrote:
>> >>
>> >> On 11/18/2012 4:31 PM, Manu wrote:
>> >>>
>> >>> If I told you this is how real should be implemented, would you vote
>> >>> ++?
>> >>> What
>> >>> about double? Why?
>> >>> Why not float for that matter? There seems like no reason for the
>> >>> language to
>> >>> define any floating point type at all if you consider this
>> >>> acceptable...
>> >>
>> >>
>> >> Because they are implemented in hardware. It's pretty dang hard for a
>> >> compiler to look at a floating point emulator and figure out "gee, I
>> >> have a
>> >> nice hardware instruction that does the same thing as this 2K of code!"
>> >
>> >
>> > Right, and this is my point precisely. It's hard for GDC for instance to
>> > hook some complex library because it happens to have hardware to do it.
>> >
>> >>> 'half' isn't some custom float for niche use, it's an established
>> >>> standard,
>> >>> implemented in vastly more hardware than implements 'real'.
>> >>
>> >>
>> >> It's implemented in GPUs, sure, but it is it implemented in hardware
>> >> that
>> >> D runs on? (I do know about this:
>> >> http://gcc.gnu.org/onlinedocs/gcc/Half_002dPrecision.html)
>> >>
>> >> There is no major technical difficulty in implementing it as a basic
>> >> type,
>> >> but I want to be sure we've exhausted the library approach first.
>> >
>> >
>> > Well it's available in hardware on basically all mobile devices (that's
>> > a
>> > LOT of devices (in the billions)), but even if it's just implemented in
>> > software (x86), the values are consumed by the GPU, and the validity of
>> > the
>> > values is no less important. It still seems like a valuable 1st class
>> > type;
>> > why shouldn't it enjoy the same casting, assignment, literal, range
>> > checking
>> > rules as the rest of the floats? Additionally, convenience and
>> > compatibility
>> > with generic code would be significantly improved.
>> > I don't see how it can be made to feel seamless with a lib... and that
>> > sounds like an awful lot more work.
>> >
>> >
>> > Anyway, I'm not desperate for this personally. I just wondered how
>> > people
>> > felt about it in general, and if it was something that should/would be
>> > seriously considered.
>>
>> I'm neither here nor there.  I'm just pointing out that you are
>> proposing a dedicated type to be introduced that is supported on only
>> one platform. :-)
>
>
> real is only supported on one platform (x86, it's deprecated in x64 and x87
> will likely be removed/emulated in the future), but I think many here
> consider it valuable(?).
> And that's not strictly true either, virtually every machine has a GPU, and
> host software still has to process data for it. I'm mainly encouraging this
> for the sake of correctness/type safety, though hardware support on ARM
> would be a particularly nice bonus.
>
> I also wanted to gauge the interest/opposition.

Real is mapped to the target's long double.  It could be 64bit, 80bit,
96bit, or 128bit.  The phobos math library already caters for this.
:-)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: @property needed or not needed?

[Jonathan M Davis]

On Monday, November 19, 2012 22:04:02 Rob T wrote:
> I seriously don't think you should try to constrain coding style,
> instead it makes much more sense to provide the user with a means
> to constrain it themselves as they see fit. Look at languages
> that constrain coding style too much vs languages that don't, and
> consider the popularity among them.

Excep that i don't think that it's really a question of style. It's treating a 
function as if it were a variable, when it's not only not a variable, but it's 
not even acting like one. It's implying that the code has one set of semantics 
when it has another. Dropping parens when specifically creating a function 
which is intended to emulate a variable makes sense. But dropping parens just 
because you feel like it then makes a function look like a variable when it's 
not and not intended to even act like one. That violates the very difference 
between function and variable on even a conceptual level. It would be one 
thing to make a particular character or sequence of characters optional when 
doing so doesn't make it look like it's something else entirely  (e.g. 
optional braces don't make anything look like anything else - they just drop 
some characters, and they don't introduce any ambiguities in the process). But 
it's quite another to make those characters optional when they make one 
language construct look like another.

- Jonathan M Davis

Re: half datatype?

[monarch_dodra]

On Monday, 19 November 2012 at 19:14:43 UTC, Jonathan M Davis 
wrote:

On Monday, November 19, 2012 19:57:37 Manu wrote:

I also wanted to gauge the interest/opposition.


I'd never even _heard_ of half types before this discussion 
came up. But then

again, the same goes for SIMD.

[SNIP]

- Jonathan M Davis


What I find extremely interesting about D is how easy it is to do 
extremely low level stuff.


ASM? Built-in. SIMD: You don't even realize you're doing it. In 
C++, you have to jump through flaming loops to get that stuff 
working.


I know where I'd go for my low level needs: Not C or C++ ;)

I think it could only benefit D to have the "full low level 
package in a comprehensive high level language". It's been on a 
winning run so far anyways (IMO).

Re: @property needed or not needed?

[Rob T]

On Monday, 19 November 2012 at 20:04:24 UTC, Jonathan M Davis 
wrote:
The thing is that if @property is really an abstraction for 
variables, then it
_doesn't_ make sense to allow both, because it's _not_ a matter 
of taste.
Either it's a variable, or it's a function. Not both. And if 
it's a variable,
then obviously no parens should be used with it. And if it's a 
function, then

obviously parens should be used with it.


That makes perfect sense to me if that's what the meaning of 
@property is supposed to be, and if so then it can constrain the 
usage to that of a variable, which currently is not the case.


If you're viewing it as just a way to not have to use parens on 
functions,
then that's something else entirely. And if that's what we're 
looking to

support, then using @property for that makes no sense at all.


That makes sense to me as well, and indicates that the @property 
topic is getting mixed up with another topic, which concerns the 
optional use of () for empty parameter lists.


What may be forgotten, is that we currently have the ability to 
not only drop the (), but also to perform optional assignments, 
eg Foo = 23;, without defining a function Foo to be @property.


In one case we're talking about variable abstractions, and in 
another case we're talking about simply making () optional, these 
are two entirely separate topics that are mangled up together.


I think you understand this already, but perhaps not everyone 
else does.


To further complicate things, I find that when deciding to define 
a function as @property or not is like trying to decide if Pluto 
is a planet or not, it's often not clear which way you should go, 
and that may be why I really did enjoy not having to specify 
@property to make use of the semantics it (was supposed to) 
provide when and where I saw fit to do so.


Personally, I hate the fact it's legal to have any kind of 
optional parens. I
think that it's incredibly sloppy and goes against the 
abstractions of
variables and functions. I'm all for forcing the full set of 
parens in a long

chain of UFCS. But clearly plenty of other folks don't agree.


I seriously don't think you should try to constrain coding style, 
instead it makes much more sense to provide the user with a means 
to constrain it themselves as they see fit. Look at languages 
that constrain coding style too much vs languages that don't, and 
consider the popularity among them.


My two cents :)

--rt

Re: Is there interest in a std.http?

[Adam D. Ruppe]

On Monday, 19 November 2012 at 20:38:56 UTC, Tyler Jameson Little 
wrote:
I'd like to see an HTTP module in Phobos, but I wanted to gauge 
interest first and see if this has been discussed before.


I've been asked to put my cgi.d in phobos before (which includes 
a http server as well as a cgi, fastcgi, and scgi implementation 
of its common interface), so there's probably some interest.


I haven't put mine in just because I'm not particularly motivated 
to go through the red tape.


The file is cgi.d in here:
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

Feel free to take whatever you want from it. There's also an 
extremely minimal http.d file in there, which is a very simple 
http client. (I didn't go far with this though because I tend to 
use curl for most my work anyway.)




The way I did it is with a function:

void handleRequest(Cgi cgi) { }

And then there's a mixin called GenericMain that calls your 
function.


mixin GenericMain!handleRequest;


Depending on how you compile it, the main function constructs the 
cgi object differently. -version=fastcgi means it is plugged into 
a FastCGI loop. version=scgi ditto. -version=embedded_httpd 
includes a simple little threaded http server. No version builds 
it as a standard CGI binary, one process per request. However it 
is compiled though, the Cgi methods all remain the same, so your 
function shouldn't have to change.



* Access to underlying TcpSocket (for protocol upgrades, like 
WebSocket)


My cgi.d I don't think can do this yet. I've been thinking about 
adding it though, but haven't.



* HTTP body is a stream


class Cgi has a method onRequestBodyDataReceived and one 
handleIncomingDataChunk which can be overridden by subclasses to 
do this kind of thing.


It's a bit of a pain though, I made it thinking you'd want to 
handle it after it is all loaded.



* Simple HTTP requests


This is where I think my cgi.d is a winner because most the data 
is available so easily


cgi.get["foo"] returns a string
cgi.getArray["foo"] returns an array of strings

ditto for post

cgi.request("foo", 0) returns with a default value, converting 
types as requested


There's also members like cookie, queryString, host, etc., that 
gives nice access to other headers.


* Errors can be recovered from (allow user-defined error 
handlers):

* User settable size limits


eh, I'm partially there on these. There's some constructor args 
you can play with and some degree of exception catching but 
probably not fully what you have in mind.

Re: half datatype?

[Walter Bright]

On 11/19/2012 12:28 PM, Rob T wrote:

In any case, the point is that I don't think the D community should overlook
what the game devs are doing, they're pushing D to its limits and are making D
more visible than perhaps anyone.


I agree.

I might also point out that adoption of a language (or any new technology) often 
happens because it solves a problem for an otherwise overlooked niche, and their 
adoption of it drives it into the mainstream.

Re: half datatype?

[Walter Bright]

On 11/19/2012 8:04 AM, Manu wrote:

Well it's available in hardware on basically all mobile devices (that's a LOT of
devices (in the billions)), but even if it's just implemented in software (x86),
the values are consumed by the GPU, and the validity of the values is no less
important. It still seems like a valuable 1st class type; why shouldn't it enjoy
the same casting, assignment, literal, range checking rules as the rest of the
floats? Additionally, convenience and compatibility with generic code would be
significantly improved.
I don't see how it can be made to feel seamless with a lib... and that sounds
like an awful lot more work.


By making a library type that implicitly converts to/from float, and then doing 
the operations on float, that should about cover it.


For the ARM, the conversion itself could be done by a builtin function, which 
can use the ARM hardware instruction for it.


For literals, I think:

__fp16(3.5)

coupled with UTFE can work.



Anyway, I'm not desperate for this personally. I just wondered how people felt
about it in general, and if it was something that should/would be seriously
considered.


I think it should be considered.

Is there interest in a std.http?

[Tyler Jameson Little]

I'd like to see an HTTP module in Phobos, but I wanted to gauge 
interest first and see if this has been discussed before.


An example of how I would like to interface with it (for creating 
a server):


interface HTTPHandler {
void serveHTTP(Request, Response);
}

class CustomHandler : HTTPHandler {

void serveHTTP(Request req, Response res) {
}
}

auto handler = new CustomHandler(); // implements http.Handler
auto server = new HttpServer(handler);
server.listen("0.0.0.0", 80);

As long as serveHttp() is thread safe, the http server could be 
concurrent or evented (with libev or similar) and the custom 
handler code wouldn't have to change.


I'm willing to put in the lion's share of the work (I've already 
written a bunch of it), but I'd naturally like to get some 
community input so I don't go in a completely wrong direction. 
I'm thinking of emulating Go's http library 
(http://golang.org/pkg/net/http), but of course D style.


I think the following are necessary:

* Access to underlying TcpSocket (for protocol upgrades, like 
WebSocket)

* HTTP body is a stream
* Simple HTTP requests
* Errors can be recovered from (allow user-defined error 
handlers):

* User settable size limits
  * Size of request line (1024 bytes by default)
  * Size of each header (1024 bytes by default)
  * Total size of header block (4096 bytes by default)

So, basically I'm looking for two things:

1. Interest level: willing to writ code, willing to test, want to 
use

2. Suggestions for the API/behavior

Re: half datatype?

[Rob T]

On Monday, 19 November 2012 at 19:14:43 UTC, Jonathan M Davis 
wrote:
I'd never even _heard_ of half types before this discussion 
came up. But then
again, the same goes for SIMD. And IIRC, there was some sort of 
function
attribute relating to pointers and registers that you or some 
other gaming
person was insisting on a while back, and I'd never heard of it 
existing in
C++ either (as an extension or otherwise). You clearly program 
in a very
different world than I do. I care about high performance in 
what I do but
nothing on _that_ level. I suspect that this is another one of 
those things
that certain folks would really like to have, and most of the 
rest of us don't
have any real interest in and often know nothing about in the 
first place. I
don't know that I really care whether it's added to the 
language though. I'll

leave that sort of decision up to Walter.

If anything, I just find it interesting how many low level 
things folks like
you keep coming up with as must-haves or very strong wants that 
I've never
even heard of and will almost certainly never care about aside 
perhaps from

how having them in D might help D catch on.

- Jonathan M Davis


Anyone interested in the low precision float types, and what they 
are good for, can start here

http://www.opengl.org/wiki/Small_Float_Formats

I did not read through all of this thread, but my guess is that 
the people making the request for half float are mostly into game 
development and image processing.


When I first started investigating D as a potential C++ 
replacement, I noted that a lot of the "visible" development 
(what I could see being publicized) was game development, so it 
seemed that for some reason a lot of the D users were also game 
developers, so there's perhaps something about D that they find 
attractive.


Why game devs are interested so much in D is interesting 
considering the GC is noted to be a problem for game devs. The 
work of H. S. Teoh comes to mind with his work on a game engine, 
that pushed the limits of the GC and std lib.


In any case, the point is that I don't think the D community 
should overlook what the game devs are doing, they're pushing D 
to its limits and are making D more visible than perhaps anyone.


--rt

Re: Bulding latest DMD and associated projects from github master

[Nathan M. Swan]

On Monday, 19 November 2012 at 00:40:10 UTC, Rob T wrote:
First I cloned everything from github master, and that went 
well but I'm now  encountering a lot of silly stumbling blocks 
due to inadequate documentation, for example it's clear how to 
build anything - period.


There may be documentation somewhere(?), but all I could find 
was this external blog post

http://xtzgzorex.wordpress.com/2011/07/31/d-building-dmd-and-phobos-on-linux/

The instructions in the blog allowed me to successfully build 
DMD src with 64-bit arch on Linux. So far so good, but I'm sure 
this is not the end of the problems I'll encounter.


Being new to this, I'll know immediately where the 
documentation is failing, so as I get stuck and unstuck I'm in 
a good position to create missing documentation or improve on 
the current documentation.


If I'm to try and contribute, I have a few questions, for 
example can anyone contribute at this level (build process)? If 
I am allowed to contribute, then what's the process for making 
contributions?


Thanks.

--rt


Check this out:
https://github.com/carlor/dlang-workspace

Re: The annoying D build system

[Andrei Alexandrescu]

On 11/19/12 3:29 AM, Jacob Carlborg wrote:

Is it just me that thinks the build system of D (DMD, Phobos, druntime,
and so on) is really annoying. I'm mostly thinking of the directory
structure that the makefiles expect.

For example, when building Phobos it will also, automatically, build
druntime, which it expects to find in the parent directory.


That's because phobos is dependent on druntime.


Today I tried to build the dlang.org web site. The first thing that hit
me was that it tried to build a complete release out of DMD by default.


That is because the current site docs must include the current druntime 
and phobos docs. In turn, those must be built with the currently 
released compiler. To automate all that, the build makes sure the latest 
released compiler is built and then the docs for the latest released 
libs are built.


Before that we were in the situation that updating the site was putting 
whatever was in the Phobos head (or worse, what was on the machine the 
site was built on).



Sure that can be consider my fault since I didn't check what targets the
makefile would run by default. But this makefile will also expect DMD,
Phobos and so on to be in the parent directory. It will also expect that
its own folder is named "d-programming-language.org". I renamed that to
"dlang.org" since it's shorter and that's what the site is called these
days, but that completely broke the makefile. The makefile is looking
explicitly for a folder named "d-programming-language.org", i.e.
"../d-programming-language.org/std.ddoc".


That's the name of the github project.


I think it's really annoying, and slightly scary, that the build system
breaks out of its own directory, doing things in the parent directory
and expects a certain parent directory structure.


The makefiles have evolved organically out of clear and simple 
necessities. Also, they could use some love because there was more focus 
on solving specific automation issues, rather than on a globally nice 
system.


So if you have ideas on how to improve the above - great! Just don't 
fall for Chesterton's fence fallacy.



Andrei

Re: Bulding latest DMD and associated projects from github master

[Alex Rønne Petersen]

On 19-11-2012 20:50, Rob T wrote:

On Monday, 19 November 2012 at 19:02:18 UTC, Alex Rønne Petersen wrote:


Updated the blog post, thanks.


There's errors/incompleteness with the following:


Next, we build Phobos, which is the standard library containing
facilities for concurrency, regular expressions, I/O, signals, math,
text manipulation, and so on:

cp /usr/src/phobos;
gmake -f posix.mak MODEL=64 DMD=../dmd/src/dmd;


You should tell the user to cd into the correct folder first, and fix
the cp command which is missing the source component.

Excellent instructions otherwise, and a copy of these instructions
should be included along with the sources. We'll also need a version for
building & installing on Windows which is also absent from the sources.

--rt


That was supposed to say cd, not cp. Fixed.

--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: @property needed or not needed?

[monarch_dodra]

On Monday, 19 November 2012 at 18:58:21 UTC, Era Scarecrow wrote:

On Monday, 19 November 2012 at 18:21:55 UTC, Mehrdad wrote:

Why don't we just outright disallow expression-statements?

After all,

2 + 3;

should not be a valid statement, and so

foo.property;

should not be, either.


 Hmmm I would say if it's const/immutable and pure then it 
would be an error (Side effects considered after all), 
otherwise popFront may not work (it is a property I 
believe...right?).


... wrong ;)

front is a property. popFront is a method.

 So let's assume I make some struct to call the PC Speaker (for 
whatever reason) then the following would break.


struct PCSpeaker {
  int dingsCalled;
  void ding() @property {
dingsCalled++;
//some low level calls
  }
}

 However if it was...

  void ding() @property const pure

 We know there's no side effects (and it can't modify the 
struct), which then 'ding' could be an error on it's own 
(Although without a return value that would make the signature 
completely useless).


You could argue that since a property-function is meant to 
emulate an attribute, that calling one and doing nothing is 
*always* wrong, regardless of side effect. I mean, in the sense 
that doing the side effect would make no sense if there is no 
consumer for the side effect in question.


Back to retro: I think that it actually could be an attribute. In 
that case, when you write:


a.retro;

then there is no consumer, and it creates a compile error.

After thinking about more, I think a great definition of property 
would be "a function that returns a value that *must* be 
consumed". This would give it more power than the mere 
parenthesis, no-parenthesis status: Imagine "chain" 
property-attributed. In that case:


chain(a, b);

This would fail to compile, because there is no consumer for 
chain, regardless of side effect...

Re: @property needed or not needed?

[Jonathan M Davis]

On Monday, November 19, 2012 21:42:25 Dmitry Olshansky wrote:
> 11/19/2012 7:18 PM, monarch_dodra пишет:
> > On Monday, 19 November 2012 at 14:58:29 UTC, Andrei Alexandrescu wrote:
> >> On 11/19/12 4:01 AM, monarch_dodra wrote:
> >>> I kind of agree with Jonathan here. @property really shines when you
> >>> want to "add" an attribute to a struct.
> >> 
> >> I kind of agree with him, too, but it would be a mistake to not reckon
> >> a change in dynamics. UFCS makes all those extra parens just awkward,
> >> and people will vote with their code regardless whether some
> >> particular viewpoint from some particular angle considers the approach
> >> backwards.
> >> 
> >> Andrei
> > 
> > One of the things that we may want to take into account, is that
> > -property prevents any existing function from migrating to/from
> > property. For example, if we want to make "retro" a property, we can't
> > without breaking any and all UFCS usage of retro.
> 
> The major problem about @property enforcement as it stands is that it
> breaks the duality of things like retro:
> a.retro
> vs
> retro(a)
> 
> Both should be allowed as it's a matter of taste that shouldn't be
> enforced. A lot of new code uses a.retro and a lot of older code uses
> retro(a).
> 
> If retro is property then only the first one compiles
> If retro is a function then only the second one compiles.
> 
> Which obviously means @property has to be reconsidered.

The thing is that if @property is really an abstraction for variables, then it 
_doesn't_ make sense to allow both, because it's _not_ a matter of taste. 
Either it's a variable, or it's a function. Not both. And if it's a variable, 
then obviously no parens should be used with it. And if it's a function, then 
obviously parens should be used with it.

If you're viewing it as just a way to not have to use parens on functions, 
then that's something else entirely. And if that's what we're looking to 
support, then using @property for that makes no sense at all.

Personally, I hate the fact it's legal to have any kind of optional parens. I 
think that it's incredibly sloppy and goes against the abstractions of 
variables and functions. I'm all for forcing the full set of parens in a long 
chain of UFCS. But clearly plenty of other folks don't agree.

Because of all of those folks, it may make sense to make it so that parens are 
optional on functions but are outright verboten on @property functions. That 
way, anyone wanting to use @property for actual properties can do so with 
proper enforcement, but those who want to just leave parens off of normal 
function calls can. I really don't like the idea, but at this point, I think 
that it's fairly clear that there are a lot of people who _like_ the sloppy 
nature of being able to leave parens off much as a number of the rest of us 
hate it.

- Jonathan M Davis

Re: Bulding latest DMD and associated projects from github master

[Rob T]

On Monday, 19 November 2012 at 19:02:18 UTC, Alex Rønne Petersen 
wrote:


Updated the blog post, thanks.


There's errors/incompleteness with the following:

Next, we build Phobos, which is the standard library containing 
facilities for concurrency, regular expressions, I/O, signals, 
math, text manipulation, and so on:


cp /usr/src/phobos;
gmake -f posix.mak MODEL=64 DMD=../dmd/src/dmd;


You should tell the user to cd into the correct folder first, and 
fix the cp command which is missing the source component.


Excellent instructions otherwise, and a copy of these 
instructions should be included along with the sources. We'll 
also need a version for building & installing on Windows which is 
also absent from the sources.


--rt

Re: Multidimensional array operator overloading

[Mike Wey]

On 11/19/2012 07:04 PM, H. S. Teoh wrote:

I'm experimenting with implementing "true" multidimensional arrays in D.
It's actually very nice, compared with the hassle of memory management
in C/C++, and it even lets you give opIndex multiple parameters so that
you can write things like arr[1,2] instead of the uglier arr[1][2] (or
worse, arr[2][1]).

Two questions, though:

1) Is multidimensional slicing supported? I.e., does opSlice support
notation like arr[1..2, 2..3]?


This is currently not supported. Would be nice to have tough.


2) Is opDollar supported for multidimensional arrays? I.e., when you
write arr[1..$, 2..$], the $ in each dimension can potentially be
different values (say you have a 2x3 array, so the first $ is 2, and the
second $ is 3)?


size_t opDollar(int dim)()
{

}

Where dim is the dimension in witch the $ is being used.


D will totally rock if these features are supported.


T



--
Mike Wey

Re: half datatype?

[Jonathan M Davis]

On Monday, November 19, 2012 19:57:37 Manu wrote:
> I also wanted to gauge the interest/opposition.

I'd never even _heard_ of half types before this discussion came up. But then 
again, the same goes for SIMD. And IIRC, there was some sort of function 
attribute relating to pointers and registers that you or some other gaming 
person was insisting on a while back, and I'd never heard of it existing in 
C++ either (as an extension or otherwise). You clearly program in a very 
different world than I do. I care about high performance in what I do but 
nothing on _that_ level. I suspect that this is another one of those things 
that certain folks would really like to have, and most of the rest of us don't 
have any real interest in and often know nothing about in the first place. I 
don't know that I really care whether it's added to the language though. I'll 
leave that sort of decision up to Walter.

If anything, I just find it interesting how many low level things folks like 
you keep coming up with as must-haves or very strong wants that I've never 
even heard of and will almost certainly never care about aside perhaps from 
how having them in D might help D catch on.

- Jonathan M Davis

Re: Bulding latest DMD and associated projects from github master

[Alex Rønne Petersen]

On 19-11-2012 15:46, Joseph Rushton Wakeling wrote:

On 11/19/2012 01:40 AM, Rob T wrote:

There may be documentation somewhere(?), but all I could find was this
external
blog post
http://xtzgzorex.wordpress.com/2011/07/31/d-building-dmd-and-phobos-on-linux/



Probably the reason why no official docs exist is because that blog post
actually serves the purpose ... :-P

Don't know about you, but I found that when building Phobos I had to not
just

  cp -r std /usr/local/include/d2

but also,

  cp -r etc /usr/local/include/d2

... in order for D programs to build without an error related to zlib.


Updated the blog post, thanks.

--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: @property needed or not needed?

[Era Scarecrow]

On Monday, 19 November 2012 at 18:21:55 UTC, Mehrdad wrote:

Why don't we just outright disallow expression-statements?

After all,

 2 + 3;

should not be a valid statement, and so

 foo.property;

should not be, either.


 Hmmm I would say if it's const/immutable and pure then it would 
be an error (Side effects considered after all), otherwise 
popFront may not work (it is a property I believe...right?).


 So let's assume I make some struct to call the PC Speaker (for 
whatever reason) then the following would break.


struct PCSpeaker {
  int dingsCalled;
  void ding() @property {
dingsCalled++;
//some low level calls
  }
}

 However if it was...

  void ding() @property const pure

 We know there's no side effects (and it can't modify the 
struct), which then 'ding' could be an error on it's own 
(Although without a return value that would make the signature 
completely useless).

Re: @property needed or not needed?

[David Nadlinger]

On Monday, 19 November 2012 at 18:02:06 UTC, Adam D. Ruppe wrote:
On Monday, 19 November 2012 at 15:01:36 UTC, Andrei 
Alexandrescu wrote:

Would you please start a DIP with a paste of this idea?


here it is:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP21


Thanks a lot for doing this! It's a pity that the last bigger 
discussion didn't lead anywhere, I don't think there was much 
disagreement. Hopefully, having a DIP to discuss will catalyze 
the process a bit.


David

Re: @property needed or not needed?

[Dmitry Olshansky]

11/19/2012 9:58 PM, monarch_dodra пишет:

On Monday, 19 November 2012 at 17:42:28 UTC, Dmitry Olshansky wrote:

11/19/2012 7:18 PM, monarch_dodra пишет:

On Monday, 19 November 2012 at 14:58:29 UTC, Andrei Alexandrescu wrote:

On 11/19/12 4:01 AM, monarch_dodra wrote:

I kind of agree with Jonathan here. @property really shines when you
want to "add" an attribute to a struct.


I kind of agree with him, too, but it would be a mistake to not reckon
a change in dynamics. UFCS makes all those extra parens just awkward,
and people will vote with their code regardless whether some
particular viewpoint from some particular angle considers the approach
backwards.

Andrei


One of the things that we may want to take into account, is that
-property prevents any existing function from migrating to/from
property. For example, if we want to make "retro" a property, we can't
without breaking any and all UFCS usage of retro.



The major problem about @property enforcement as it stands is that it
breaks the duality of things like retro:
a.retro
vs
retro(a)

Both should be allowed as it's a matter of taste that shouldn't be
enforced. A lot of new code uses a.retro and a lot of older code uses
retro(a).

If retro is property then only the first one compiles
If retro is a function then only the second one compiles.

Which obviously means @property has to be reconsidered.


Hum... Perhaps you meant:
a.retro
vs
a.retro()


This one too.


Because "retro(a)" works regardless of the property.


Hm.. being a while since I tried to use -property switch. I thought it 
was also disallowed. Not so bad then I guess.


Looking forward to DIP21.


--
Dmitry Olshansky

Re: @property needed or not needed?

[Mehrdad]

Why don't we just outright disallow expression-statements?

After all,

 2 + 3;

should not be a valid statement, and so

 foo.property;

should not be, either.

Re: @property needed or not needed?

[Andrei Alexandrescu]

On 11/19/12 12:30 PM, Michel Fortin wrote:

On 2012-11-19 06:52:11 +, Andrei Alexandrescu
 said:


On 11/19/12 1:02 AM, Rob T wrote:

So what's up with @property?


It's a mistake on top of another. We need to redesign it to such that
the keyword '@property' is only required in cases that otherwise would
be ambiguous (functions returning functions).


…or functions returning a type with an opCall.

What about template functions with a parametrized return type that will
sometime be ambiguous and sometime not depending on the template
parameters?



Let's put all of these cases in a DIP so we can analyze them.

Thanks,

Andrei

Re: @property needed or not needed?

[Adam D. Ruppe]

On Monday, 19 November 2012 at 15:01:36 UTC, Andrei Alexandrescu 
wrote:

Would you please start a DIP with a paste of this idea?


here it is:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP21

I tried to implement this a while ago and hit some pain after 
some early success. The pain was trying to get assignments to 
work without breaking other cases like returning ref.


My plan was to make any reference to a @property change to a 
CallExp or whatever. But if you do that and it is on the left 
hand side of an assignment, you do the wrong thing.


foo = foo + 1;

should generally become:

foo(foo() + 1);

but if there isn't a setter, we should leave it as foo() = foo() 
+ 1; and finding the setter is a bit of a pain. Then, of course, 
we ideally want foo += 1 to work too..


Maybe someone who knows the compiler better than me will make it 
look easy though.

Multidimensional array operator overloading

[H. S. Teoh]

I'm experimenting with implementing "true" multidimensional arrays in D.
It's actually very nice, compared with the hassle of memory management
in C/C++, and it even lets you give opIndex multiple parameters so that
you can write things like arr[1,2] instead of the uglier arr[1][2] (or
worse, arr[2][1]).

Two questions, though:

1) Is multidimensional slicing supported? I.e., does opSlice support
notation like arr[1..2, 2..3]?

2) Is opDollar supported for multidimensional arrays? I.e., when you
write arr[1..$, 2..$], the $ in each dimension can potentially be
different values (say you have a 2x3 array, so the first $ is 2, and the
second $ is 3)?

D will totally rock if these features are supported.


T

-- 
Today's society is one of specialization: as you grow, you learn more
and more about less and less. Eventually, you know everything about
nothing.

Re: @property needed or not needed?

[monarch_dodra]

On Monday, 19 November 2012 at 17:42:28 UTC, Dmitry Olshansky 
wrote:

11/19/2012 7:18 PM, monarch_dodra пишет:
On Monday, 19 November 2012 at 14:58:29 UTC, Andrei 
Alexandrescu wrote:

On 11/19/12 4:01 AM, monarch_dodra wrote:
I kind of agree with Jonathan here. @property really shines 
when you

want to "add" an attribute to a struct.


I kind of agree with him, too, but it would be a mistake to 
not reckon
a change in dynamics. UFCS makes all those extra parens just 
awkward,

and people will vote with their code regardless whether some
particular viewpoint from some particular angle considers the 
approach

backwards.

Andrei


One of the things that we may want to take into account, is 
that

-property prevents any existing function from migrating to/from
property. For example, if we want to make "retro" a property, 
we can't

without breaking any and all UFCS usage of retro.



The major problem about @property enforcement as it stands is 
that it breaks the duality of things like retro:

a.retro
vs
retro(a)

Both should be allowed as it's a matter of taste that shouldn't 
be enforced. A lot of new code uses a.retro and a lot of older 
code uses retro(a).


If retro is property then only the first one compiles
If retro is a function then only the second one compiles.

Which obviously means @property has to be reconsidered.


Hum... Perhaps you meant:
a.retro
vs
a.retro()
???

Because "retro(a)" works regardless of the property.

Re: half datatype?

[Manu]

On 19 November 2012 19:28, Iain Buclaw  wrote:

> On 19 November 2012 16:04, Manu  wrote:
> > On 19 November 2012 06:19, Walter Bright 
> wrote:
> >>
> >> On 11/18/2012 4:31 PM, Manu wrote:
> >>>
> >>> If I told you this is how real should be implemented, would you vote
> ++?
> >>> What
> >>> about double? Why?
> >>> Why not float for that matter? There seems like no reason for the
> >>> language to
> >>> define any floating point type at all if you consider this
> acceptable...
> >>
> >>
> >> Because they are implemented in hardware. It's pretty dang hard for a
> >> compiler to look at a floating point emulator and figure out "gee, I
> have a
> >> nice hardware instruction that does the same thing as this 2K of code!"
> >
> >
> > Right, and this is my point precisely. It's hard for GDC for instance to
> > hook some complex library because it happens to have hardware to do it.
> >
> >>> 'half' isn't some custom float for niche use, it's an established
> >>> standard,
> >>> implemented in vastly more hardware than implements 'real'.
> >>
> >>
> >> It's implemented in GPUs, sure, but it is it implemented in hardware
> that
> >> D runs on? (I do know about this:
> >> http://gcc.gnu.org/onlinedocs/gcc/Half_002dPrecision.html)
> >>
> >> There is no major technical difficulty in implementing it as a basic
> type,
> >> but I want to be sure we've exhausted the library approach first.
> >
> >
> > Well it's available in hardware on basically all mobile devices (that's a
> > LOT of devices (in the billions)), but even if it's just implemented in
> > software (x86), the values are consumed by the GPU, and the validity of
> the
> > values is no less important. It still seems like a valuable 1st class
> type;
> > why shouldn't it enjoy the same casting, assignment, literal, range
> checking
> > rules as the rest of the floats? Additionally, convenience and
> compatibility
> > with generic code would be significantly improved.
> > I don't see how it can be made to feel seamless with a lib... and that
> > sounds like an awful lot more work.
> >
> >
> > Anyway, I'm not desperate for this personally. I just wondered how people
> > felt about it in general, and if it was something that should/would be
> > seriously considered.
>
> I'm neither here nor there.  I'm just pointing out that you are
> proposing a dedicated type to be introduced that is supported on only
> one platform. :-)
>

real is only supported on one platform (x86, it's deprecated in x64 and x87
will likely be removed/emulated in the future), but I think many here
consider it valuable(?).
And that's not strictly true either, virtually every machine has a GPU, and
host software still has to process data for it. I'm mainly encouraging this
for the sake of correctness/type safety, though hardware support on ARM
would be a particularly nice bonus.

I also wanted to gauge the interest/opposition.

Re: @property needed or not needed?

[Dmitry Olshansky]

11/19/2012 7:18 PM, monarch_dodra пишет:

On Monday, 19 November 2012 at 14:58:29 UTC, Andrei Alexandrescu wrote:

On 11/19/12 4:01 AM, monarch_dodra wrote:

I kind of agree with Jonathan here. @property really shines when you
want to "add" an attribute to a struct.


I kind of agree with him, too, but it would be a mistake to not reckon
a change in dynamics. UFCS makes all those extra parens just awkward,
and people will vote with their code regardless whether some
particular viewpoint from some particular angle considers the approach
backwards.

Andrei


One of the things that we may want to take into account, is that
-property prevents any existing function from migrating to/from
property. For example, if we want to make "retro" a property, we can't
without breaking any and all UFCS usage of retro.



The major problem about @property enforcement as it stands is that it 
breaks the duality of things like retro:

a.retro
vs
retro(a)

Both should be allowed as it's a matter of taste that shouldn't be 
enforced. A lot of new code uses a.retro and a lot of older code uses 
retro(a).


If retro is property then only the first one compiles
If retro is a function then only the second one compiles.

Which obviously means @property has to be reconsidered.

--
Dmitry Olshansky

Re: @property needed or not needed?

[Michel Fortin]

On 2012-11-19 06:52:11 +, Andrei Alexandrescu 
 said:



On 11/19/12 1:02 AM, Rob T wrote:

So what's up with @property?


It's a mistake on top of another. We need to redesign it to such that 
the keyword '@property' is only required in cases that otherwise would 
be ambiguous (functions returning functions).


…or functions returning a type with an opCall.

What about template functions with a parametrized return type that will 
sometime be ambiguous and sometime not depending on the template 
parameters?


--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca/

Re: half datatype?

[Iain Buclaw]

On 19 November 2012 16:04, Manu  wrote:
> On 19 November 2012 06:19, Walter Bright  wrote:
>>
>> On 11/18/2012 4:31 PM, Manu wrote:
>>>
>>> If I told you this is how real should be implemented, would you vote ++?
>>> What
>>> about double? Why?
>>> Why not float for that matter? There seems like no reason for the
>>> language to
>>> define any floating point type at all if you consider this acceptable...
>>
>>
>> Because they are implemented in hardware. It's pretty dang hard for a
>> compiler to look at a floating point emulator and figure out "gee, I have a
>> nice hardware instruction that does the same thing as this 2K of code!"
>
>
> Right, and this is my point precisely. It's hard for GDC for instance to
> hook some complex library because it happens to have hardware to do it.
>
>>> 'half' isn't some custom float for niche use, it's an established
>>> standard,
>>> implemented in vastly more hardware than implements 'real'.
>>
>>
>> It's implemented in GPUs, sure, but it is it implemented in hardware that
>> D runs on? (I do know about this:
>> http://gcc.gnu.org/onlinedocs/gcc/Half_002dPrecision.html)
>>
>> There is no major technical difficulty in implementing it as a basic type,
>> but I want to be sure we've exhausted the library approach first.
>
>
> Well it's available in hardware on basically all mobile devices (that's a
> LOT of devices (in the billions)), but even if it's just implemented in
> software (x86), the values are consumed by the GPU, and the validity of the
> values is no less important. It still seems like a valuable 1st class type;
> why shouldn't it enjoy the same casting, assignment, literal, range checking
> rules as the rest of the floats? Additionally, convenience and compatibility
> with generic code would be significantly improved.
> I don't see how it can be made to feel seamless with a lib... and that
> sounds like an awful lot more work.
>
>
> Anyway, I'm not desperate for this personally. I just wondered how people
> felt about it in general, and if it was something that should/would be
> seriously considered.

I'm neither here nor there.  I'm just pointing out that you are
proposing a dedicated type to be introduced that is supported on only
one platform. :-)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: Something needs to happen with shared, and soon.

[Michel Fortin]

On 2012-11-19 09:31:46 +, "foobar"  said:


On Saturday, 17 November 2012 at 13:22:23 UTC, Michel Fortin wrote:

On 2012-11-16 18:56:28 +, Dmitry Olshansky  said:


11/16/2012 5:17 PM, Michel Fortin пишет:

In case you want to protect two variables (or more) with the same mutex.
For instance:

Mutex m;
synchronized(m) int next_id;
synchronized(m) Object[int] objects_by_id;



Wrap in a struct and it would be even much clearer and safer.
struct ObjectRepository {
int next_id;
Object[int] objects_by_id;
}
//or whatever that combination indicates anyway
synchronized ObjectRepository objeRepo;


I guess that'd be fine too.




That solution does not work in the general case. More specifically any 
graph-like data structure. E.g a linked-lists, trees, etc..

Think for example an insert to a shared AVL tree.


No solution will be foolproof in the general case unless we add new 
type modifiers to the language to prevent escaping references, 
something Walter is reluctant to do. So whatever we do with mutexes 
it'll always be a leaky abstraction. I'm not too trilled by this either.


--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca/

Re: half datatype?

[Manu]

On 19 November 2012 06:19, Walter Bright  wrote:

> On 11/18/2012 4:31 PM, Manu wrote:
>
>> If I told you this is how real should be implemented, would you vote ++?
>> What
>> about double? Why?
>> Why not float for that matter? There seems like no reason for the
>> language to
>> define any floating point type at all if you consider this acceptable...
>>
>
> Because they are implemented in hardware. It's pretty dang hard for a
> compiler to look at a floating point emulator and figure out "gee, I have a
> nice hardware instruction that does the same thing as this 2K of code!"


Right, and this is my point precisely. It's hard for GDC for instance to
hook some complex library because it happens to have hardware to do it.

 'half' isn't some custom float for niche use, it's an established standard,
>> implemented in vastly more hardware than implements 'real'.
>>
>
> It's implemented in GPUs, sure, but it is it implemented in hardware that
> D runs on? (I do know about this: http://gcc.gnu.org/onlinedocs/**
> gcc/Half_002dPrecision.html
> )
>
> There is no major technical difficulty in implementing it as a basic type,
> but I want to be sure we've exhausted the library approach first.
>

Well it's available in hardware on basically all mobile devices (that's a
LOT of devices (in the billions)), but even if it's just implemented in
software (x86), the values are consumed by the GPU, and the validity of the
values is no less important. It still seems like a valuable 1st class type;
why shouldn't it enjoy the same casting, assignment, literal, range
checking rules as the rest of the floats? Additionally, convenience and
compatibility with generic code would be significantly improved.
I don't see how it can be made to feel seamless with a lib... and that
sounds like an awful lot more work.


Anyway, I'm not desperate for this personally. I just wondered how people
felt about it in general, and if it was something that should/would be
seriously considered.

Re: half datatype?

[Manu]

On 19 November 2012 06:06, Walter Bright  wrote:

> On 11/18/2012 4:23 PM, Manu wrote:
>
>> Actually, they probably will. People using it will need to use it
>> regardless of
>> how it's implemented. Hardware support it great when available, but
>> realistically, it's used when processing data for execution on another
>> processor
>> that does support it in hardware (typically a GPU). Use of fp16 is
>> probably not
>> optional; it doubles your bandwidth wherever the loss of precision is
>> acceptable.
>>
>
> Doing implicit conversions on them implies doing them on the x86 CPU,
> which has no hardware support for the type. All operations would require
> software emulation.
>

It would just make the experience seamless, and also implement the expected
casting/data-loss rules. It's the type safety/casting rules that I find
most valuable, and the ability to use them in templates without
specialising the half path.

I guess it would be nicer/simpler to perform actual work as floats and then
re-pack it on write back, rather than emulating all the operations in half
space. This wouldn't strictly retain half precision though, it would be
slightly higher precision since the intermediates were full precision
(which is surely preferable?).

If it is a storage-only format, then what role do implicit conversions play?
>

It saves pack/unpack calls whenever interacting with them in structs or
streams, which helps generic code. And also encourages use of the type in
structs, as it is not an 'inconvenience' as such. Where I'm from,
memory/bandwidth is often far more scarce than processing time.
x86 can do half conversion fairly efficiently (about 5 opcodes, possibly
one of the reasons it hasn't found it's way into SSE yet). But it's no
surprise that platforms like ARM implemented the conversion operations in
hardware, there's no time to waste on mobile devices.

I've also seen a few threads on this forum before about people targeting
GPU backends to do GPGPU processing with D. Has that ever actually been
used? Found useful in practise?

Re: @property needed or not needed?

[monarch_dodra]

On Monday, 19 November 2012 at 14:58:29 UTC, Andrei Alexandrescu 
wrote:

On 11/19/12 4:01 AM, monarch_dodra wrote:
I kind of agree with Jonathan here. @property really shines 
when you

want to "add" an attribute to a struct.


I kind of agree with him, too, but it would be a mistake to not 
reckon a change in dynamics. UFCS makes all those extra parens 
just awkward, and people will vote with their code regardless 
whether some particular viewpoint from some particular angle 
considers the approach backwards.


Andrei


One of the things that we may want to take into account, is that 
-property prevents any existing function from migrating to/from 
property. For example, if we want to make "retro" a property, we 
can't without breaking any and all UFCS usage of retro.

Re: @property needed or not needed?

[Andrei Alexandrescu]

On 11/19/12 8:18 AM, Adam D. Ruppe wrote:

On Monday, 19 November 2012 at 06:52:11 UTC, Andrei Alexandrescu wrote:

We need to redesign it to such that the keyword '@property' is only
required in cases that otherwise would be ambiguous (functions
returning functions).


There's a fairly easy way to do this, thanks to the @property word:

[snip]

Would you please start a DIP with a paste of this idea?

Andrei

Re: @property needed or not needed?

[Andrei Alexandrescu]

On 11/19/12 4:01 AM, monarch_dodra wrote:

I kind of agree with Jonathan here. @property really shines when you
want to "add" an attribute to a struct.


I kind of agree with him, too, but it would be a mistake to not reckon a 
change in dynamics. UFCS makes all those extra parens just awkward, and 
people will vote with their code regardless whether some particular 
viewpoint from some particular angle considers the approach backwards.


Andrei

Re: split dmd frontend into separate project

[Joseph Rushton Wakeling]

On 11/19/2012 08:24 AM, Thomas Koch wrote:

while browsing the sources of gdc, ldc and dmd I noticed that gdc and ldc
both include the verbatim frontend source code from dmd.

Wouldn't it make sense to split the free dmd frontend into a standalone
project that could then easier be referenced also by gdc and ldc?


I think Iain Buclaw is working on this, though the realization will probably 
come only after some other GDC priorities are addressed:

http://forum.dlang.org/post/mailman.1565.1352137245.5162.d@puremagic.com

Re: Bulding latest DMD and associated projects from github master

[Joseph Rushton Wakeling]

On 11/19/2012 01:40 AM, Rob T wrote:

There may be documentation somewhere(?), but all I could find was this external
blog post
http://xtzgzorex.wordpress.com/2011/07/31/d-building-dmd-and-phobos-on-linux/


Probably the reason why no official docs exist is because that blog post 
actually serves the purpose ... :-P


Don't know about you, but I found that when building Phobos I had to not just

 cp -r std /usr/local/include/d2

but also,

 cp -r etc /usr/local/include/d2

... in order for D programs to build without an error related to zlib.

Re: split dmd frontend into separate project

[Iain Buclaw]

On 19 November 2012 07:24, Thomas Koch  wrote:
> Hi,
>
> while browsing the sources of gdc, ldc and dmd I noticed that gdc and ldc
> both include the verbatim frontend source code from dmd.
>
> Wouldn't it make sense to split the free dmd frontend into a standalone
> project that could then easier be referenced also by gdc and ldc?
>
> I'm also asking because I was surprised that debian also contains (a very
> old version of) ldc[1]. If one day we'd have proper d packages in Debian, it
> would surely be nice to have only one d frontend package instead of three
> times the same source code in different packages.
>
> [1] http://packages.qa.debian.org/l/ldc.html
>
> Regards, Thomas Koch

Yes it would make sense - no it can't be done because gdc/ldc makes
changes to their own copies of dfe.  The solution would be to fix dfe
so that multiple backends can use it.  But that it not currently the
case.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Bret Victor - Inventing on Principle

[Regan Heath]

Hope no-one minds..

I stumbled across this video which I thought was pretty darn cool:
http://www.youtube.com/watch?v=PUv66718DII

R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Time for std.reflection

[Adam D. Ruppe]

On Monday, 19 November 2012 at 11:43:36 UTC, sclytrack wrote:

You could do something like this:
string currentModule(alias T = {})() { return __traits(parent, 
T).stringof; }

Re: @property needed or not needed?

[Adam D. Ruppe]

On Monday, 19 November 2012 at 06:52:11 UTC, Andrei Alexandrescu 
wrote:
We need to redesign it to such that the keyword '@property' is 
only required in cases that otherwise would be ambiguous 
(functions returning functions).


There's a fairly easy way to do this, thanks to the @property 
word:


1) Any function without @property remains exactly the same as it 
is now. Parens are *not* required on them.


2) Any function with @property is rewritten into a call 
immediately. Therefore, putting () is naturally an error or 
delegate call because of the return value.


@property int foo() {}

foo; // rewritten into foo() transparently
foo(); // since foo is already foo(), this becomes foo()() - an 
error because you cannot call an int like a function




The only potential for code breakage here is on stuff marked 
@property, which if you have been marking it on semantic 
properties already (NOT on places where you just wanted appease 
the -property switch's idiotic rules), should be fine.


If in doubt, leave @property off. That leaves things exactly as 
they are.

foreach on const(V[K])

[Dan]

I posted this on *learn* a few days back.
Is this a reasonable language request - to allow for ref of 
immutable(K) on associative array iteration? If allowed it would 
enable iteration without casting, because casting could allow for 
unintended consequences. Maybe there is another way?


The original is at this link and contents are copied below.
http://forum.dlang.org/post/rxobffxfqbqotyhmr...@forum.dlang.org

Thanks
Dan


Wouldn't a better form for foreach on associative arrays be one
of:

*case 1*
foreach(ref immutable(K) k; ref V v) {
}

*case 2*
foreach(ref immutable(K) k; ref const(V) v) {
}

Both of these would allow for iterating over const associative
arrays without *copying* the key K. As it stands you can not
iterate, or even get the length (which under the covers does
iteration) of a const(V[K]) without casting off const deeply
because the foreach approach is to copy the keys. But it should
not need to? Couldn't it allow a reference to the keys and the
type on iteration of the key should be immutable.

In the example below casting is the only way to get at length and
on the iteration the keys are (needlessly?) copied.

Thanks,
Dan

- OUTPUT ---
Length:
1
Foreach:
Key dupped
k => a val => b
-
import std.stdio;
const int asPreferred = 0;
struct Key {
  this(this){ c=c.dup; writeln("Key dupped"); }
  char[] c;
}
struct Val {
  this(this){ c=c.dup; writeln("Val dupped"); }
  char[] c;
}
alias Val[Key] Map;
void foo(ref const(Map) m) {
  static if(asPreferred) {
writeln(m.length);
foreach(ref immutable(K) k, ref const(Val) v; m) {}
  } else {
writeln("Length:");
writeln((cast(Val[Key])m).length);
writeln("Foreach:");
foreach(k,ref Val v; cast(Val[Key])m) {
  writeln("k => ", k.c, " val => ", v.c);
}
  }
}

void main() {
  Val[Key] aa = [ Key(['a']) : Val(['b']) ];
  foo(aa);
}

Re: Time for std.reflection

[sclytrack]

In the latter case, the module needs to save all needed 
information for

ri, so it should plant this:

// inside std.algorithm
mixin(makeModuleInfoAvailableDynamically());



Is there a way to get the current module at compile time?

__traits(allMembers, pkg.modulename)

Re: @property needed or not needed?

[Jonathan M Davis]

On Monday, November 19, 2012 12:31:02 sclytrack wrote:
> So is it official? We keep the d1 syntax for none property
> functions? Even the assignment?

No. It's not official. No decision has been made. For the moment, nothing has 
changed about @property. It may very well change, but nothing has happened but 
some discussion on the matter, and while Andrei is suggesting may very well be 
what happens, not everyone agrees with his assessment. We'll have to wait and 
see.

- Jonathan M Davis

Re: @property needed or not needed?

[sclytrack]

So is it official? We keep the d1 syntax for none property 
functions? Even the assignment?


So for the dynamic stuff opDispatch only (for properties and 
methods)? The ()() syntax remains for the dynamic delegate 
properties.

Re: The annoying D build system

[Andrej Mitrovic]

On 11/19/12, Jacob Carlborg  wrote:
> Is it just me that thinks the build system of D (DMD, Phobos, druntime,
> and so on) is really annoying. I'm mostly thinking of the directory
> structure that the makefiles expect.

Well on win32 I have two directories on my drive, "dmd" and "dmd-git".
"dmd" is an official release, while "dmd-git" is git-head. The dir
structure is:

dmd-git\dmd2\src\dmd  <- git-head
dmd-git\dmd2\src\druntime <- git-head
dmd-git\dmd2\src\phobos <- git-head
dmd-git\dmd2\windows\  ... <- binaries, etc

"dmd-git" is in the PATH env variable before "dmd" so it always
overrides it. When I want to switch between using git-head and an
official release I append an underscore to "dmd-git" (a shortcut key
can do the trick using autohotkey).

It's the simplest system I could think of..

Re: Something needs to happen with shared, and soon.

[foobar]

On Saturday, 17 November 2012 at 13:22:23 UTC, Michel Fortin 
wrote:
On 2012-11-16 18:56:28 +, Dmitry Olshansky 
 said:



11/16/2012 5:17 PM, Michel Fortin пишет:
In case you want to protect two variables (or more) with the 
same mutex.

For instance:

Mutex m;
synchronized(m) int next_id;
synchronized(m) Object[int] objects_by_id;



Wrap in a struct and it would be even much clearer and safer.
struct ObjectRepository {
int next_id;
Object[int] objects_by_id;
}
//or whatever that combination indicates anyway
synchronized ObjectRepository objeRepo;


I guess that'd be fine too.




That solution does not work in the general case. More 
specifically any graph-like data structure. E.g a linked-lists, 
trees, etc..

Think for example an insert to a shared AVL tree.

Re: @property needed or not needed?

[Rob T]

On Monday, 19 November 2012 at 08:23:43 UTC, Jonathan M Davis 
wrote:
Which completely violates the concept of a property in the 
first place. It's
intended to be an abstraction for a variable. Using @property 
just to get rid
of parens would be like naming types with verbs instead of 
nouns. It's

completely backwards.

- Jonathan M Davis


I know what you are saying, but I know that most people will 
usually follow the path of least resistance, so if a lot of 
people really dislike typing in () all over the place and are 
given a way out, then they'll likely take it, so long as it won't 
matter in any significant way in terms of practicality.


Another case that I would say violates the property concept, is a 
getter property function that returns a non-const ref, and 
reusing the same property function as a setter (for cases where 
there's nothing to be done when setting). It is less work when 
you can get away with defining one property function that looks 
like two, even though it may be bad in some way, I expect it will 
be done often.


I suppose with @property enforcement in place, the compiler can 
be adjusted to prevent non-const ref return values for property 
getters. That would also make it a bit more difficult to specify 
@property just to get rid of typing ().


The big question is what do we gain and what do we lose from 
enforcements like this? It has to be worth doing, or it should 
not be done,


Personally, I think we're much better off not attempting to 
enforce coding style through restrictions that could be viewed as 
unnecessary.


--rt

Re: Something needs to happen with shared, and soon.

[Sönke Ludwig]

Am 19.11.2012 05:57, schrieb deadalnix:
> Le 17/11/2012 05:49, Jason House a écrit :
>> On Thursday, 15 November 2012 at 16:31:43 UTC, Sean Kelly wrote:
>>> On Nov 11, 2012, at 6:30 PM, Walter Bright
>>>  wrote:

 To make a shared type work in an algorithm, you have to:

 1. ensure single threaded access by aquiring a mutex
 2. cast away shared
 3. operate on the data
 4. cast back to shared
 5. release the mutex
>>>
>>>
>>> So what happens if you pass a reference to the now non-shared object
>>> to a function that caches a local reference to it? Half the point of
>>> the attribute is to protect us from accidents like this.
>>
>> The constructive thing to do may be to try and figure out what should
>> users be allowed to do with locked shared data... I think the basic idea
>> is that no references can be escaped; SafeD rules could probably help
>> with that. Non-shared member functions might also need to be tagged with
>> their ability to be called on locked, shared data.
> 
> Nothing is safe if ownership cannot be statically proven. This is completely 
> useless.

But you can at least prove ownership under some limited circumstances. Limited, 
but (without having
tested on a large scale) still practical.

Interest seems to be limited much more than those circumstances, but anyway:
http://forum.dlang.org/thread/k831b6$1368$1...@digitalmars.com

(the same approach that I already posted in this thread, but in a state that 
should be more or less
bullet proof)

Re: @property needed or not needed?

[monarch_dodra]

On Monday, 19 November 2012 at 08:45:03 UTC, thedeemon wrote:
On Monday, 19 November 2012 at 08:23:43 UTC, Jonathan M Davis 
wrote:

On Monday, November 19, 2012 09:16:29 Rob T wrote:
My guess is that if @property gets enforced, we'll see a lot 
of
functions with empty parameter lists being defined as 
@property

for the sole reason to get rid of having to type in the ().


Which completely violates the concept of a property in the 
first place. It's
intended to be an abstraction for a variable. Using @property 
just to get rid
of parens would be like naming types with verbs instead of 
nouns. It's

completely backwards.

- Jonathan M Davis


I very much like the combination of UFCS, ranges and 
parens-free style which allows writing code like


iota(0, 
100).map!(to!string).retro.take(50).retro[10].writeln;


So I like Andrei's idea to force @property only for those 
functions where it's absolutely necessary to fight ambiguity.


I kind of agree with Jonathan here. @property really shines when 
you want to "add" an attribute to a struct. array "front", for 
example, is a perfect example of this. RefCounted's "payload" 
(IMO), is also a good example.


*Functions* that do actual operations, in particular, "retro", 
IMO, should not be properties.


"byLines", for example, is a member function, and not property. 
How is:

r.retro;
any better than
r.byLines()
?

At best, it makes it look like r has a built-in retro attribute, 
which is miss-leading.



I'll admit I thought too it would be "convenient" to write 
".retro" without the parens, but let's face it, that'd be 
incorrect usage...

Re: @property needed or not needed?

[thedeemon]

On Monday, 19 November 2012 at 08:23:43 UTC, Jonathan M Davis 
wrote:

On Monday, November 19, 2012 09:16:29 Rob T wrote:

My guess is that if @property gets enforced, we'll see a lot of
functions with empty parameter lists being defined as @property
for the sole reason to get rid of having to type in the ().


Which completely violates the concept of a property in the 
first place. It's
intended to be an abstraction for a variable. Using @property 
just to get rid
of parens would be like naming types with verbs instead of 
nouns. It's

completely backwards.

- Jonathan M Davis


I very much like the combination of UFCS, ranges and parens-free 
style which allows writing code like


iota(0, 100).map!(to!string).retro.take(50).retro[10].writeln;

So I like Andrei's idea to force @property only for those 
functions where it's absolutely necessary to fight ambiguity.

The annoying D build system

[Jacob Carlborg]

Is it just me that thinks the build system of D (DMD, Phobos, druntime, 
and so on) is really annoying. I'm mostly thinking of the directory 
structure that the makefiles expect.


For example, when building Phobos it will also, automatically, build 
druntime, which it expects to find in the parent directory.


Today I tried to build the dlang.org web site. The first thing that hit 
me was that it tried to build a complete release out of DMD by default. 
Sure that can be consider my fault since I didn't check what targets the 
makefile would run by default. But this makefile will also expect DMD, 
Phobos and so on to be in the parent directory. It will also expect that 
its own folder is named "d-programming-language.org". I renamed that to 
"dlang.org" since it's shorter and that's what the site is called these 
days, but that completely broke the makefile. The makefile is looking 
explicitly for a folder named "d-programming-language.org", i.e. 
"../d-programming-language.org/std.ddoc".


I think it's really annoying, and slightly scary, that the build system 
breaks out of its own directory, doing things in the parent directory 
and expects a certain parent directory structure.


--
/Jacob Carlborg

Re: @property needed or not needed?

[Jonathan M Davis]

On Monday, November 19, 2012 09:16:29 Rob T wrote:
> My guess is that if @property gets enforced, we'll see a lot of
> functions with empty parameter lists being defined as @property
> for the sole reason to get rid of having to type in the ().

Which completely violates the concept of a property in the first place. It's 
intended to be an abstraction for a variable. Using @property just to get rid 
of parens would be like naming types with verbs instead of nouns. It's 
completely backwards.

- Jonathan M Davis

Re: @property needed or not needed?

[Rob T]

On Monday, 19 November 2012 at 06:53:46 UTC, Andrei Alexandrescu 
wrote:
I think UFCS changes the playfield quite a lot. Code using UFCS 
looks a whole lot crappier with a bunch of arbitrary extra 
parens.



Andrei


I'm making good use out of UFCS functions that work like 
properties, so to remain consistent with struct/class calling 
syntax, I would expect to have the ability to define functions 
that have property semantics at the module level.


I really think that modules should have properties anyway, and 
since I can do it, I am doing it, and it works great.


My guess is that if @property gets enforced, we'll see a lot of 
functions with empty parameter lists being defined as @property 
for the sole reason to get rid of having to type in the ().


--rt