"Szymon Gatner" <noemail@gmail.com> writes:
>
> That is good to hear indeed. In your estimate: how much longer until D is usable on iOS?

Depends on your definition of "usable" Szymon.

If it is just me working on it, I think a standalone LDC cross compiler to 32-bit arm devices with druntime/phobos can be ready in a few months. Maybe early first quarter 2015.  By standalone I mean just the LDC toolchain.

This would allow a D library to be embedded in an otherwise Objective-C
(or maybe Swift?) iOS app.

How about bindings for APIs in the iPhone SDK?  I think folks can build those as needed with help from Jacob's dstep tool.  It would be nice to have a repository for these bindings somewhere though.

It would be cool if by Feb/Mar 2015 a demo app could be submited to the App Store, just to test acceptance.  I think Walter's D version of "Empire", but with the original ASCII character graphics, would be a fun choice ;-)

I really don't know how to predict the timing for the following:

Objective-C interop (DIP 43).  Without it, it will be hard to go all out "D" in an iOS app.  I have not been following the pull request and don't have any idea when it might bubble into LDC via DMD, but not anytime soon I would guess.  Would it be good to merge it onto a LDC+iOS git branch?  Just as a temporary proof of concept?

Then there are all the tool related things that might hinder D use on iOS.  Things such as no source level debugging, lack of D/Xcode integration.

Oh, and compiling to arm64 for newer devices.
-- 
dano

On Wednesday, 15 October 2014 at 06:29:40 UTC, Daniel N wrote:
> "C++03 has this syntax to oblige the compiler to instantiate a template:
>
> template class std::vector<MyClass>;"

But how does D handle concepts which most likely will be in the C++14 standard?

http://concepts.axiomatics.org/~ans/

On Tuesday, 14 October 2014 at 20:41:25 UTC, Nick Sabalausky wrote:
> On 09/30/2014 04:48 AM, Szymon Gatner wrote:
>> On Monday, 29 September 2014 at 20:15:06 UTC, bachmeier wrote:
>>> On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner wrote:
>>>
>>>
>>> Is that all it would take? Do you also need a GC-free standard
>>> library, which seems to be the need of all the others saying "do this
>>> and I'll switch from C++"? Are the tools good enough?
>>
>> Considered how many games (and I don't mean indie anymore, but for
>> example Blizzard's Heartstone) are now created in Unity which uses not
>> only GC but runs in Mono I am very skeptical of anybody claiming GC is a
>> no-go for games.
>
> The whole "Unity3D == Mono" thing is a somewhat inaccurate misconception.
>
> Unity3D's engine (ie, the real workhorse of any Unity3D game) is written in plain old native C++. So not *necessarily* GC (though they might still use one internally, I wouldn't know).
>
> Only the game-specific scripts (and I *think* the Unity3D Editor) actually run on Mono. And even then, the game scripts *are* able to call into C-linkage stuff, which *is* occasionally done to work around performance issues within game scripts.
>
> Also, I imagine Mono's GC is probably quite a bit better than D's currently is.

Yeah, but on the other hand there are quite a few small studios living off Air, LibGDX/jMonkeyEngine and XNA/MonoGame.

Which is an area where D could also appeal to indies.

One needs to start somewhere.

--
Paulo

On Wednesday, 15 October 2014 at 06:50:55 UTC, Dan Olson wrote:
> "Szymon Gatner" <noemail@gmail.com> writes:
>>
>> That is good to hear indeed. In your estimate: how much longer until D
>> is usable on iOS?
>
> Depends on your definition of "usable" Szymon.
>
>
> This would allow a D library to be embedded in an otherwise Objective-C
> (or maybe Swift?) iOS app.

That is my definition :)

I would use static D library in C++ iOS application.

>
> How about bindings for APIs in the iPhone SDK?  I think folks can build
> those as needed with help from Jacob's dstep tool.  It would be nice to
> have a repository for these bindings somewhere though.

Would be nice but much less important for me.

>
> It would be cool if by Feb/Mar 2015 a demo app could be submited to the
> App Store, just to test acceptance.

I would gladly do that

>
> Then there are all the tool related things that might hinder D use on
> iOS.  Things such as no source level debugging, lack of D/Xcode
> integration.

Right

>
> Oh, and compiling to arm64 for newer devices.

Knowing Apple that will be mandatory for new apps soon.

Thanks for all your work!

On Tuesday, 14 October 2014 at 22:27:35 UTC, Walter Bright wrote:
>
> Currently, D supports C++:
>
> * function calling
> * name mangling
> * namespaces
> * templates
> * member functions
> * single inheritance
> * basic types that exist in C++ but not D (like 'long')
>
I get the sense that http://dlang.org/cpp_interface needs some updates then?  At the very least, it mentions "...it is very unlikely that any sort of reasonable method could be found to express C++ templates in a link-compatible way with D."

Or am I misunderstanding what you mean with that bullet point?

-Wyatt

"Wyatt"  wrote in message news:vhwivrusiysydgkxrjqw@forum.dlang.org... 

> I get the sense that http://dlang.org/cpp_interface needs some updates then?  At the very least, it mentions "...it is very unlikely that any sort of reasonable method could be found to express C++ templates in a link-compatible way with D."
> 
> Or am I misunderstanding what you mean with that bullet point?

That page is many years out of date.

On 2014-10-15 08:50, Dan Olson wrote:

> This would allow a D library to be embedded in an otherwise Objective-C
> (or maybe Swift?) iOS app.

Sure, as long as it's using an Objective-C compatible API.

> How about bindings for APIs in the iPhone SDK?  I think folks can build
> those as needed with help from Jacob's dstep tool.  It would be nice to
> have a repository for these bindings somewhere though.

I will create Dub packages when I need some framework, unless someone else beats me to it.

> Objective-C interop (DIP 43).  Without it, it will be hard to go all out
> "D" in an iOS app.  I have not been following the pull request and don't
> have any idea when it might bubble into LDC via DMD, but not anytime
> soon I would guess.

It needs some refactoring, which I've already started.

> Then there are all the tool related things that might hinder D use on
> iOS.  Things such as no source level debugging

I think I have used Xcode to debug a D application.

> lack of D/Xcode integration.

Yeah, it will be far from as convenient as using Swift but I think it's possible. Most tools Xcode uses: compiling, build nib files and so on are command line tools. For example, TextMate is using Ninja as a build system, completely without Xcode. It still uses nib files and other OS X specific features.

-- 
/Jacob Carlborg

On 10/14/14, 11:18 PM, Jacob Carlborg wrote:
> On 2014-10-15 01:01, Andrei Alexandrescu wrote:
>
>> Correct. Here's the syntax on the C++ side:
>> http://en.wikipedia.org/wiki/C++11#Extern_template -- Andrei
>
> "extern template class std::vector<MyClass>;
>
> which tells the compiler NOT to instantiate the template in this
> translation unit."
>
> That sounds like the complete opposite of what's needed.

C++11 includes C++03. -- Andrei

Am 15.10.2014 um 09:18 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>":
> On Wednesday, 15 October 2014 at 06:29:40 UTC, Daniel N wrote:
>> "C++03 has this syntax to oblige the compiler to instantiate a template:
>>
>> template class std::vector<MyClass>;"
>
> But how does D handle concepts which most likely will be in the C++14
> standard?
>
> http://concepts.axiomatics.org/~ans/

I imagine you meant C++17. C++14 is already ratified.

--
Paulo

On Wednesday, 15 October 2014 at 17:38:46 UTC, Paulo Pinto wrote:
>
> I imagine you meant C++17. C++14 is already ratified.

Yes, sorry, I meant that it is close enough for consideration as a draft. So discussing the effects of it on D's C++ support is now possible?