220 24663 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: String View Status? Date: Thu, 25 Feb 2016 07:41:32 -0800 (PST) Lines: 146 Approved: news@gmane.org Message-ID: References: <90aa729e-e9b7-436f-abe5-ed856f0fd561@isocpp.org> <477b147e-f082-4ccd-b286-0c174f02321d@isocpp.org> <5bf5ca4e-c38d-4e75-abd0-7181708d73b7@isocpp.org> <1f0bc9e9-79a9-468a-bd66-080096a19861@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_915_238138560.1456414892864" X-Trace: ger.gmane.org 1456414896 3353 80.91.229.3 (25 Feb 2016 15:41:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Feb 2016 15:41:36 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBLWBXS3AKGQE4ACC24A@isocpp.org Thu Feb 25 16:41:36 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f197.google.com ([209.85.223.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aYy2p-0006Yy-Sa for gclcip-std-proposals@m.gmane.org; Thu, 25 Feb 2016 16:41:36 +0100 Original-Received: by mail-io0-f197.google.com with SMTP id 70sf107344460iok.1 for ; Thu, 25 Feb 2016 07:41:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=/upKP0LBnMYk2ptVioPi1i8qRDRwysQHPWvAfkREBX8=; b=wqKfs9Rs4cvaiZ028ugzxj3bxUoqjJ0WZXi07yuYX6nuzxEXK1GAt+VsZsPKCJjREh FFCYx5KYG+Lkufj37xuYsTmtbVrhIWQR4dQf1jQZqC8xAsCeTK8avBtFq9f8WAC7CKxb YmdGcnvq2JwQdYjNMqxWWdlA5LVB1gHsEwilPn0hXA0jHPugsseZPeqh680vY+/N4q75 qEy+1MMeOesT8dBv6XoCDWOKeLER5WgU/dj2OFhhmpsGwEVeUJk5yUu5zc+vKrDbKfV5 plYAqKEgk9HGuxCK3Zc63wxS/UcXhhNKfcWICdkLGGBSLQar46AD3rN0NiM7x13R7Mml Bc6w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=/upKP0LBnMYk2ptVioPi1i8qRDRwysQHPWvAfkREBX8=; b=gQFu1BhqKOUdcCzuWMNrAqDkCjcbfdOdGB+RYQbOJP3Iw/4DK8kFPXVVCD4LHjSE2M iJfmGTHbZya9UhaQ1Z8jh7sGZgoP4U8HfclYLn4Ned5hbipo6aPNe0ZpZnGm//eFJd41 95Mc5ma0dxZ1yzrTXGFausAgYkb5TWkD4nHiq0kjQ8iz5RgpfmPhTdywv/US60DEO7+Y qbnESGebcDDfmUX4O/v9b8agNDtTT7uM/pWRvLznQ+Bl4RJXoZKywI6qEyWesB1ccwHv waqUNVkleff+8vrmHxTqg603kxUE5w0KUXZ6y4Kac/M3WoaQpaAwyMcZtQIhaEb1xKLW 58pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=/upKP0LBnMYk2ptVioPi1i8qRDRwysQHPWvAfkREBX8=; b=RAsp4dBAhAqn8fhNhJB+xitUrPuPQMlObapGBFO4Qvwvxf6YP6vqdPtOh67EMpNGJ7 AKfaHLEsQmN+EtM7LQ5DQHeLk/D8cQx6USQwXbkIJb8nfZF1l5iy62uO+Ezt5RYmbq/u tuh5tQbgRPgr64m9bV0afr12oeFxEBoXpr726Ik/e3DxEd3Dvye1M/DvMm/rILMS7yOe 5UycytKg6cLzjtDWWHYvPVHUdZpAW89ujroVVkeaomyj87FCt5WkYyHNi+VlumNvqiH+ oC1vUoVKHLGbXrK6XxE4Fozh7gDJcXtlT7qLcC91L1X102CH1+bStLYldDDWDhciXTwZ b4RQ== X-Gm-Message-State: AG10YOQ30GIShdANh77zv4fxOgRW9LJYmc9Xa7K+mJdJtFksIFLIjQtlZTOrE+3o2vS6rA== X-Received: by 10.50.154.2 with SMTP id vk2mr3028980igb.9.1456414894882; Thu, 25 Feb 2016 07:41:34 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.15.105 with SMTP id x102ls446362ioi.65.gmail; Thu, 25 Feb 2016 07:41:33 -0800 (PST) X-Received: by 10.50.109.161 with SMTP id ht1mr80106igb.1.1456414893902; Thu, 25 Feb 2016 07:41:33 -0800 (PST) In-Reply-To: X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:24663 Archived-At: ------=_Part_915_238138560.1456414892864 Content-Type: multipart/alternative; boundary="----=_Part_916_295089532.1456414892864" ------=_Part_916_295089532.1456414892864 Content-Type: text/plain; charset=UTF-8 On Wednesday, February 24, 2016 at 2:10:18 PM UTC-5, Ville Voutilainen wrote: > > On 24 February 2016 at 19:43, Nicol Bolas > > wrote: > > On Wednesday, February 24, 2016 at 9:54:45 AM UTC-5, Ville Voutilainen > > wrote: > >> > >> On 24 February 2016 at 16:44, Nicol Bolas wrote: > >> >> I'm definitely looking for use cases for modifying the data pointed > to > >> >> by > >> >> a string_view, where you're not equally well-served by a span. > >> > You mean besides the very important semantic distinction between > "this > >> > is an > >> > array of bytes" and "this is a string"? A function that takes > >> > `span` > >> > is taking a byte array. A function that takes `string_span` > could > >> > is > >> > taking a string and it will interpret its bytes as such. > >> > >> I don't quite follow what you mean by "taking a string and will > >> interpret its bytes as such". > > > > > > That it might do things with it that you do with strings, which are > distinct > > from actions you take with arbitrary byte arrays. > > Well, neither string_view nor string_span guarantee that you're > dealing with a "string", whatever you > choose to mean by that. > .... I'm not sure what your point is. If you have a class called "string_span", and you feel the need to fill it with non-string data, C++ won't stop you. Just like if you have a `basic_string`, and you feel the need to fill it with non-string data, C++ won't stop you. C++ isn't a safe language. But that doesn't mean that semantic meaning cannot/should not be expressed by the type system. After all, that is *exactly* why people want strong aliases; so that values which are technically `int` and `float` and so forth can have actual semantic meanings to the type system. So that you can't just pass a naked `float` to a function; you have to give it a specific semantic meaning beyond `float`. Having a string type that is semantically distinct from "array of bytes" is a *good thing*. -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a02492f4-144e-4027-bb54-35b94759dae0%40isocpp.org. ------=_Part_916_295089532.1456414892864 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, February 24, 2016 at 2:10:18 PM UTC-5, Ville= Voutilainen wrote:
On 24 Febru= ary 2016 at 19:43, Nicol Bolas <jmck...@gmail.com> wrote:
> On Wednesday, February 24, 2016 at 9:54:45 AM UTC-5, Ville Voutila= inen
> wrote:
>>
>> On 24 February 2016 at 16:44, Nicol Bolas <jmck...@gmail= ..com> wrote:
>> >> I'm definitely looking for use cases for modifyin= g the data pointed to
>> >> by
>> >> a string_view, where you're not equally well-serv= ed by a span<char>.
>> > You mean besides the very important semantic distinction = between "this
>> > is an
>> > array of bytes" and "this is a string"? A = function that takes
>> > `span<char>`
>> > is taking a byte array. A function that takes `string_spa= n<char>` could
>> > is
>> > taking a string and it will interpret its bytes as such.
>>
>> I don't quite follow what you mean by "taking a strin= g and will
>> interpret its bytes as such".
>
>
> That it might do things with it that you do with strings, which ar= e distinct
> from actions you take with arbitrary byte arrays.

Well, neither string_view nor string_span guarantee that you're
dealing with a "string", whatever you
choose to mean by that.

... I'm not sure what your point is.

I= f you have a class called "string_span", and you feel the need to= fill it with non-string data, C++ won't stop you. Just like if you hav= e a `basic_string`, and you feel the need to fill it with non-string data, = C++ won't stop you.

C++ isn't a safe language.

But th= at doesn't mean that semantic meaning cannot/should not be expressed by= the type system. After all, that is exactly why people want strong = aliases; so that values which are technically `int` and `float` and so fort= h can have actual semantic meanings to the type system. So that you can'= ;t just pass a naked `float` to a function; you have to give it a specific = semantic meaning beyond `float`.

Having a string type that is semant= ically distinct from "array of bytes" is a good thing.
=

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/a02492f4-144e-4027-bb54-35b94759dae0= %40isocpp.org.
------=_Part_916_295089532.1456414892864-- ------=_Part_915_238138560.1456414892864-- .