On 2012-05-09 02:56, Sean Cavanaugh wrote:

> Thousands of my C/C++ floating point constants are broken by the CTFE
> change since as 'integer'-like float constants 31.f and won't compile
> anymore, since its trying to do f(31) to them for me now . . .

I don't see any point in supporting 31.f as a floating point syntax.

-- 
/Jacob Carlborg

On Wednesday, 9 May 2012 at 08:16:35 UTC, Alex Rønne Petersen wrote:
>>
>> I personally use "import core.stdc" as an indicator that there may be some feature missing from Phobos.  It's easily greppable, and easy to avoid using the routines.  In fact, I think "import core" anything should be an exceptional case in a typical D application.  Everything exposed in Druntime is for what I'd consider power users.  Unsafe threads, runtime and GC hooks, platform API calls, etc.  It's all there because the higher-level stuff needs it, but is really not intended for general use.
>>
>
> I just hope none of it goes away. I make extensive use of many core.* modules.
>

Could you please provide more details about your use-cases?
As Sean said, it might indicate missing functionality in Phobos.
Keep in mind we were specifically discussing the C APIs which are an external dependency. No one suggests removing the low-level druntime APIs such as GC hooks.

>> Once upon a time, there was a D runtime library (unrelated to Druntime) that has no C library dependence at all.  It was an interesting idea, but I don't know that there's any system that D targets which doesn't support C.
>
> *Is* there any system that doesn't support C? ;)

It isn't only a question of whether the system supports C or not. There are many considerations when choosing your tool-chain. For instance, the reference implementation of some languages is implemented in ML for its correctness properties. EcmaScript for instance uses ML for the language/runtime.
In the JS case, it doesn't necessarily mean your browser will run ML, it just means the highly optimized vendor implementation has an official correct version to compare to.

In the D world, we have a few projects that aim to implement a D compiler using D. Why would such a compiler/runtime need to provide C APIs if it's completely written in D?

On 09/05/12 10:16, Alex Rønne Petersen wrote:
> On 08-05-2012 23:48, Sean Kelly wrote:
>> On May 8, 2012, at 2:31 PM, Jonathan M Davis wrote:
>>>
>>> We've previously discussed having _all_ of the C system call
>>> functions from
>>> the various OSes that we support being in druntime, and I very much
>>> think that
>>> that's the right way to go. Phobos and druntime then have whatever
>>> they need
>>> as for as standard C and system call functions go, and anyone who
>>> needs any
>>> which aren't wrapped by Phobos in some manner has them available to
>>> them.
>>> Anyone that doesn't want to use any of those C function directly,
>>> doesn't have
>>> to, but I don't see any reason to hide them just because someone
>>> doesn't want
>>> to use them in their code.
>>>
>>> If the problem is that certain C functions end up getting used a lot
>>> when they
>>> should have D wrappers of some kind which better encapsulate their
>>> functionality, then maybe we add the appropriate wrappers to Phobos. But
>>> that's a completely different issue. Hiding the C functions doesn't
>>> help us
>>> any.
>>
>> I personally use "import core.stdc" as an indicator that there may be
>> some feature missing from Phobos. It's easily greppable, and easy to
>> avoid using the routines. In fact, I think "import core" anything
>> should be an exceptional case in a typical D application. Everything
>> exposed in Druntime is for what I'd consider power users. Unsafe
>> threads, runtime and GC hooks, platform API calls, etc. It's all there
>> because the higher-level stuff needs it, but is really not intended
>> for general use.
>>
>
> I just hope none of it goes away. I make extensive use of many core.*
> modules.
>
>>
>>> It makes sense to make truly internal stuff internal, but the standard C
>>> function declarations and OS system functions are _not_ internal to
>>> druntime.
>>> They're _very_ much external. druntime is just providing them because
>>> they're
>>> functionality which is core to the system that any D program is
>>> running on.
>>
>> Once upon a time, there was a D runtime library (unrelated to
>> Druntime) that has no C library dependence at all. It was an
>> interesting idea, but I don't know that there's any system that D
>> targets which doesn't support C.
>
> *Is* there any system that doesn't support C? ;)

There are plenty of systems that don't support C99 perfectly.

On 5/9/12, Don Clugston <dac@nospam.com> wrote:
> OK, looks like it's a different bug. Please put in bugzilla, with status of regression.

It turns out it's not a regression:
http://d.puremagic.com/issues/show_bug.cgi?id=8082
Something odd about module compilation order which makes unrelated
modules error out.

On 5/11/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> It turns out it's not a regression:
> http://d.puremagic.com/issues/show_bug.cgi?id=8082
> Something odd about module compilation order which makes unrelated
> modules error out.
>

In my project making sure my main.d file is compiled *last* reduces the error count from ~400 lines to just 2 error lines.

On 09-05-2012 10:27, Jacob Carlborg wrote:
> On 2012-05-09 02:56, Sean Cavanaugh wrote:
>
>> Thousands of my C/C++ floating point constants are broken by the CTFE
>> change since as 'integer'-like float constants 31.f and won't compile
>> anymore, since its trying to do f(31) to them for me now . . .
>
> I don't see any point in supporting 31.f as a floating point syntax.
>

+1.

-- 
- Alex

forum.dlang.org apparently failed to post this 10 minutes ago, retrying.

On Tuesday, 10 July 2012 at 02:43:05 UTC, Era Scarecrow wrote:
> On Tuesday, 10 July 2012 at 01:41:29 UTC, bearophile wrote:
>> David Piepgrass:
>>> This use case is pretty complex, so if I port this to D, I'd probably just cast away const/immutable where necessary.
>>
>> You are not the first person that says similar things. So D docs need to stress more than casting away const/immutable in D is rather more dangerous than doing the same thing in C++.
...
>  Let's say a class/struct is a book with Page protectors signifying 'const(ant)'. You promise to return the book to the library without making any changes; Although you promised you wouldn't make changes, you still take the Page protectors off and make make notes on the outer edges or make adjustments in the text, then return the book.
>
>  Is this wise? This isn't C++. If something shouldn't change, then don't change it god damn it. If it needs to change it isn't const(ant) and shouldn't suggest it is.

The difficulty, in case you missed it, is that somebody else (the Object class) says that certain functions are const, but in certain cases we really, really want to mutate something, either for efficiency or because "that's just how the data structure works". If a data structure needs to mutate itself when read, yeah, maybe its functions should not be marked const, but quite often the "const" is inherited from Object or some interface that (quite reasonably, it would seem) expects functions that /read stuff/ to be const.

And yet we can't drop const from Object or such interfaces, because there is other code elsewhere that /needs/ const to be there.

So far I have no solution to the dilemma in mind, btw. But the idea someone had of providing two (otherwise identical) functions, one const and one non-const, feels like a kludge to me, and note that anybody with an object would expect to be able to call the const version on any Object.

> Seriously, it's not that hard a concept. I guess if something doesn't port well from C++ then redesign it. Some things done in C++ are hacks due to the language's limitations and faults.

I was referring to a potential port from C#, which has no const. My particular data structure (a complex beast) contains a mutable tree of arbitrary size, which the user can convert to a conceptually immutable tree in O(1) time by calling Clone(). This marks a flag in the root node that says "read-only! do not change" and shares the root between the clones. At this point it should be safe to cast the clone to immutable. However, the original, mutable-typed version still exists. As the user requests changes to the mutable copy in the future, parts of the tree are duplicated to avoid changing the immutable nodes, with one exception: the read-only flag in various parts of the original, immutable tree will gradually be set to true.

In this case, I don't think the D type system could do anything to help ensure that I don't modify the original tree that is supposed to be immutable. Since the static type of internal references must either be all mutable or all immutable, they will be typed mutable in the mutable copy, and immutable in the immutable copy, even though the two copies are sharing the same memory.

And one flag, the read-only flag, must be mutable in this data structure, at least the transition from false->true must happen *after* the immutable copy is created; otherwise, Clone() would have to run in O(N) time, to mark every node read-only. This fact, however, does not affect the immutable copy in any way.