Sorry if this is a repeat, but I’d like to suggest promoting certain structs from Foundation to the Swift standard library.
As an OS X and iOS developer, it sometimes seems that I work with [GG|NS]Point, [GG|NS]Rect, and [GG|NS]Size almost as much as I use Float or String. I’d love to see Swift’s standard library include Rect, Point, and Size types, with bridging to make them “just work” with any UIKit or AppKit API that expects their NS or CG equivalents. Maybe also typealias Frame and Bounds to Rect while we’re at it.
Sorry if this is a repeat, but I’d like to suggest promoting certain structs from Foundation to the Swift standard library.
As an OS X and iOS developer, it sometimes seems that I work with [GG|NS]Point, [GG|NS]Rect, and [GG|NS]Size almost as much as I use Float or String. I’d love to see Swift’s standard library include Rect, Point, and Size types, with bridging to make them “just work” with any UIKit or AppKit API that expects their NS or CG equivalents. Maybe also typealias Frame and Bounds to Rect while we’re at it.
Do you use them a lot outside of a Cocoa/UIKit context?
Félix
···
Le 6 janv. 2016 à 00:08:35, John Randolph via swift-evolution <swift-evolution@swift.org> a écrit :
Sorry if this is a repeat, but I’d like to suggest promoting certain structs from Foundation to the Swift standard library.
As an OS X and iOS developer, it sometimes seems that I work with [GG|NS]Point, [GG|NS]Rect, and [GG|NS]Size almost as much as I use Float or String. I’d love to see Swift’s standard library include Rect, Point, and Size types, with bridging to make them “just work” with any UIKit or AppKit API that expects their NS or CG equivalents. Maybe also typealias Frame and Bounds to Rect while we’re at it.
As an OS X and iOS developer, it sometimes seems that I work with [GG|NS]Point, [GG|NS]Rect, and [GG|NS]Size almost as much as I use Float or String. I’d love to see Swift’s standard library include Rect, Point, and Size types, with bridging to make them “just work” with any UIKit or AppKit API that expects their NS or CG equivalents. Maybe also typealias Frame and Bounds to Rect while we’re at it.
Thoughts?
My main thought is that, although I use these types in my iOS and Mac apps all the time, I think I've used a rectangle type in web development maybe once (when I was generating images). Swift is currently used mainly for GUI programming, but most of the domains it's expanding into are ones where it doesn't need those types.
I'm ot particularly enthusiastic about the suggested Frame and Bounds typealiases though. You could still assign a Bounds to a Frame so I don't think that there's a big win here.
Félix
···
Le 6 janv. 2016 à 00:10:31, John Randolph via swift-evolution <swift-evolution@swift.org> a écrit :
Sorry if this is a repeat, but I’d like to suggest promoting certain structs from Foundation to the Swift standard library.
As an OS X and iOS developer, it sometimes seems that I work with [GG|NS]Point, [GG|NS]Rect, and [GG|NS]Size almost as much as I use Float or String. I’d love to see Swift’s standard library include Rect, Point, and Size types, with bridging to make them “just work” with any UIKit or AppKit API that expects their NS or CG equivalents. Maybe also typealias Frame and Bounds to Rect while we’re at it.
I don't think Point, Rect... belong to the standard library - but nonetheless, there should be a standard lib where they belong to:
I think C++ suffered a lot because there is no point-structure that is well accepted. Many people declared own, incompatible variants with the same boring traits — and most would have simply used the default implementation, if there had been one.
So what I would like to see is a set of official supported libs to cover basic topics like graphics and math, and constructs like Box and Either.
Those libs could declare interfaces for common tasks and evolve beside the stdlib, serving a task similar to what boost does in C++.
It’s a feature that would be useful in the areas where Swift is being used today. Whether a feature is important in other domains doesn’t make it any less useful in Swift’s current applications.
-jcr
···
On Jan 5, 2016, at 10:10 PM, Brent Royal-Gordon <brent@architechies.com> wrote:
As an OS X and iOS developer, it sometimes seems that I work with [GG|NS]Point, [GG|NS]Rect, and [GG|NS]Size almost as much as I use Float or String. I’d love to see Swift’s standard library include Rect, Point, and Size types, with bridging to make them “just work” with any UIKit or AppKit API that expects their NS or CG equivalents. Maybe also typealias Frame and Bounds to Rect while we’re at it.
Thoughts?
My main thought is that, although I use these types in my iOS and Mac apps all the time, I think I've used a rectangle type in web development maybe once (when I was generating images). Swift is currently used mainly for GUI programming, but most of the domains it's expanding into are ones where it doesn't need those types.
I support this, not because I find NS- and CG- geometric structs confusing.
I support it because I'm hoping Swift library versions would be generic. I
would be very glad to see us get *Rect<Double>* or *Point<Int>* as part of
the standard library.
···
On Wed, Jan 6, 2016 at 9:32 PM, John Randolph via swift-evolution < swift-evolution@swift.org> wrote:
> On Jan 5, 2016, at 10:10 PM, Brent Royal-Gordon <brent@architechies.com> > wrote:
>
>> As an OS X and iOS developer, it sometimes seems that I work with
[GG|NS]Point, [GG|NS]Rect, and [GG|NS]Size almost as much as I use Float or
String. I’d love to see Swift’s standard library include Rect, Point, and
Size types, with bridging to make them “just work” with any UIKit or AppKit
API that expects their NS or CG equivalents. Maybe also typealias Frame
and Bounds to Rect while we’re at it.
>>
>> Thoughts?
>
> My main thought is that, although I use these types in my iOS and Mac
apps all the time, I think I've used a rectangle type in web development
maybe once (when I was generating images). Swift is currently used mainly
for GUI programming, but most of the domains it's expanding into are ones
where it doesn't need those types.
It’s a feature that would be useful in the areas where Swift is being used
today. Whether a feature is important in other domains doesn’t make it any
less useful in Swift’s current applications.
I like that. I can certainly think of situations where I might want integer based rectangles, sizes, and points.
-jcr
···
On Jan 6, 2016, at 9:51 PM, Charles Constant <charles@charlesism.com> wrote:
I support this, not because I find NS- and CG- geometric structs confusing. I support it because I'm hoping Swift library versions would be generic. I would be very glad to see us get Rect<Double> or Point<Int> as part of the standard library.
Rect, Point, Size, EdgeInsets are all ripe for this but I would prefer a
Generic implementation as Charles Constant pointed out. Obj-C compatibility
is a problem for the generic idea.
···
On Thu, Jan 7, 2016 at 12:51 AM, Charles Constant via swift-evolution < swift-evolution@swift.org> wrote:
I support this, not because I find NS- and CG- geometric structs
confusing. I support it because I'm hoping Swift library versions would be
generic. I would be very glad to see us get *Rect<Double>* or *Point<Int>* as
part of the standard library.
On Wed, Jan 6, 2016 at 9:32 PM, John Randolph via swift-evolution < > swift-evolution@swift.org> wrote:
> On Jan 5, 2016, at 10:10 PM, Brent Royal-Gordon <brent@architechies.com> >> wrote:
>
>> As an OS X and iOS developer, it sometimes seems that I work with
[GG|NS]Point, [GG|NS]Rect, and [GG|NS]Size almost as much as I use Float or
String. I’d love to see Swift’s standard library include Rect, Point, and
Size types, with bridging to make them “just work” with any UIKit or AppKit
API that expects their NS or CG equivalents. Maybe also typealias Frame
and Bounds to Rect while we’re at it.
>>
>> Thoughts?
>
> My main thought is that, although I use these types in my iOS and Mac
apps all the time, I think I've used a rectangle type in web development
maybe once (when I was generating images). Swift is currently used mainly
for GUI programming, but most of the domains it's expanding into are ones
where it doesn't need those types.
It’s a feature that would be useful in the areas where Swift is being
used today. Whether a feature is important in other domains doesn’t make
it any less useful in Swift’s current applications.
I can certainly think of situations where I might want integer based
rectangles, sizes, and points.
I'm quite biased this week, because I spent *yesterday* writing a file for
my project with "IntRect" "IntPoint" "IntSize" ad nauseam. It's not
something I'm very thrilled to have as part of my Audio app - a lone file
of geometric structs that aready exist if you use CGFloats, where I don't
get the full implementation, etc. And previously, I've written code that I
needed land on whole numbers, and the extra concern about finding the right
options in Cocoa to do so just stressed me out.
···
On Wed, Jan 6, 2016 at 11:24 PM, John Randolph <jcr@icloud.com> wrote:
On Jan 6, 2016, at 9:51 PM, Charles Constant <charles@charlesism.com> > wrote:
I support this, not because I find NS- and CG- geometric structs
confusing. I support it because I'm hoping Swift library versions would be
generic. I would be very glad to see us get *Rect<Double>* or *Point<Int>* as
part of the standard library.
I like that. I can certainly think of situations where I might want
integer based rectangles, sizes, and points.
FWIW, NSIntegralRect() and CGRectIntegral() do exist. Note their entirely different naming conventions. ;-)
Would be much nicer to just use myRect.integralRect when I need to round it. Might also be nice to have myRect.roundedOut and myRect.roundedIn for a bit more control of which way the sides move.
-jcr
···
On Jan 6, 2016, at 11:38 PM, Charles Constant <charles@charlesism.com> wrote:
> I can certainly think of situations where I might want integer based rectangles, sizes, and points.
I'm quite biased this week, because I spent *yesterday* writing a file for my project with "IntRect" "IntPoint" "IntSize" ad nauseam. It's not something I'm very thrilled to have as part of my Audio app - a lone file of geometric structs that aready exist if you use CGFloats, where I don't get the full implementation, etc. And previously, I've written code that I needed land on whole numbers, and the extra concern about finding the right options in Cocoa to do so just stressed me out.
But that's conversion though, right? That's part of what I find stressful.
If I'm using Ints internally, I don't ever need to worry about getting
wonky results because of floating point math.
···
On Wed, Jan 6, 2016 at 11:45 PM, John Randolph <jcr@icloud.com> wrote:
> On Jan 6, 2016, at 11:38 PM, Charles Constant <charles@charlesism.com> > wrote:
>
> > I can certainly think of situations where I might want integer based
rectangles, sizes, and points.
>
> I'm quite biased this week, because I spent *yesterday* writing a file
for my project with "IntRect" "IntPoint" "IntSize" ad nauseam. It's not
something I'm very thrilled to have as part of my Audio app - a lone file
of geometric structs that aready exist if you use CGFloats, where I don't
get the full implementation, etc. And previously, I've written code that I
needed land on whole numbers, and the extra concern about finding the right
options in Cocoa to do so just stressed me out.
FWIW, NSIntegralRect() and CGRectIntegral() do exist. Note their entirely
different naming conventions. ;-)
Would be much nicer to just use myRect.integralRect when I need to round
it. Might also be nice to have myRect.roundedOut and myRect.roundedIn for
a bit more control of which way the sides move.
I definitely think a library for generic CG compatible types would be
great. I also think the standard library may need adaptation to allow
integers and floats to be used in generic structures (there isn't common
protocols for arithmetic operators, and those operators have different
implications for signed vs unsigned, float versus integer, etc.).
However I do not think they are fundamental enough as data structures and
data types to be in the standard library.
-1
I would support something like CGVector (for 1,2,4,8... components), if
that can expose hardware vector optimisations that may not otherwise be
accessible. However that may be implemented efficiently enough with a third
party c library (like this https://github.com/mattt/Surge\), and afaik may
already be under consideration for the built-in Float types.
···
On Thu, Jan 7, 2016 at 6:54 PM, Charles Constant via swift-evolution < swift-evolution@swift.org> wrote:
> CGRectIntegral
But that's conversion though, right? That's part of what I find
stressful. If I'm using Ints internally, I don't ever need to worry about
getting wonky results because of floating point math.
On Wed, Jan 6, 2016 at 11:45 PM, John Randolph <jcr@icloud.com> wrote:
> On Jan 6, 2016, at 11:38 PM, Charles Constant <charles@charlesism.com> >> wrote:
>
> > I can certainly think of situations where I might want integer based
rectangles, sizes, and points.
>
> I'm quite biased this week, because I spent *yesterday* writing a file
for my project with "IntRect" "IntPoint" "IntSize" ad nauseam. It's not
something I'm very thrilled to have as part of my Audio app - a lone file
of geometric structs that aready exist if you use CGFloats, where I don't
get the full implementation, etc. And previously, I've written code that I
needed land on whole numbers, and the extra concern about finding the right
options in Cocoa to do so just stressed me out.
FWIW, NSIntegralRect() and CGRectIntegral() do exist. Note their
entirely different naming conventions. ;-)
Would be much nicer to just use myRect.integralRect when I need to round
it. Might also be nice to have myRect.roundedOut and myRect.roundedIn for
a bit more control of which way the sides move.